Frank Heckenbach frank@g-n-u.de writes:
Nick Burrett wrote:
Frank Heckenbach frank@g-n-u.de writes:
Honda Hirotaka wrote:
I'm trying to build gpc-20001019 on an old i486DX2 DECpc running FreBSD 2.2.8 , but I get the error message of "gcc-2.95.2/gcc/p/rts/rts.c:326: `T_RESADFLT' undeclared here (not in a function)" .
I can't find the word "T_RESADFLT" in rts.c. I want to know what is happenning.
No, this word doesn't occur. However, the line refers to ILL_RESAD_FAULT (and two lines below to ILL_RESOP_FAULT).
So, it may be that these symbols are defined to T_RESADFLT and T_RESOPFLT in some system header, but the latter symbols are not defined. Now, why would one define something to something undefined? I don't know, I guess only a C programmer can understand this...
FreeBSD doesn't use T_RESADFLT or T_RESOPFLT and therefore doesn't define them.
The ILL_* macros are defined as placeholders for a time when they might be used.
So, they define them so #ifdef ILL_... is true, but ILL_... still can't be used. Very strange, IMHO...
It is usually done as a placeholder. If people use them, then they get a compile error. Although simply not defining them at all would make no difference either.
So for FreeBSD, you will need to check that the definitions of T_RESADFLT and T_RESOPFLT exist and then fix the definition of ILL_RESAD_FAULT and ILL_RESOP_FAULT accordingly.
I'd consider this a last resort. I mean we want to use ILL_... -- why should we check whether T_... is defined? Perhaps the next system defined them to BLAH_... and whatever, what then?
Yeah, I know what you mean. I can't think of a decent answer to this one either.
The ILL_RESAD_FAULT and ILL_RESOP_FAULT are defined by FreeBSD in machine/trap.h if you are curious.
We don't include this. We include signal.h if it exists, and if not, bsd/signal.h if that exists. Probably machine/trap.h is included by one of them (or some other header we use).
signal.h includes sys/signal.h, which in turn includes machine/trap.h.
This is also where the corresponding T_* macros are defined.
Now I don't understand. You said above they're not defined, didn't you? So, should we explicitly include machine/trap.h, would that help?
I think this is best explained by simply including a chunk of the file:
/* * Trap type values * also known in trap.c for name strings */
#define T_PRIVINFLT 1 /* privileged instruction */ #define T_BPTFLT 3 /* breakpoint instruction */ #define T_ARITHTRAP 6 /* arithmetic trap */ #define T_ASTFLT 7 /* system forced exception */ #define T_PROTFLT 9 /* protection fault */ #define T_TRCTRAP 10 /* debug exception (sic) */ #define T_PAGEFLT 12 /* page fault */ #define T_ALIGNFLT 14 /* alignment fault */
#define T_DIVIDE 18 /* integer divide fault */ #define T_NMI 19 /* non-maskable trap */ #define T_OFLOW 20 /* overflow trap */ #define T_BOUND 21 /* bound instruction fault */ #define T_DNA 22 /* device not available fault */ #define T_DOUBLEFLT 23 /* double fault */ #define T_FPOPFLT 24 /* fp coprocessor operand fetch fault */ #define T_TSSFLT 25 /* invalid tss fault */ #define T_SEGNPFLT 26 /* segment not present fault */ #define T_STKFLT 27 /* stack fault */ #define T_MCHK 28 /* machine check trap */ #define T_RESERVED 29 /* reserved (unknown) */
/* XXX most of the following codes aren't used, but could be. */
/* definitions for <sys/signal.h> */ #define ILL_RESAD_FAULT T_RESADFLT #define ILL_PRIVIN_FAULT T_PRIVINFLT #define ILL_RESOP_FAULT T_RESOPFLT #define ILL_ALIGN_FAULT T_ALIGNFLT #define ILL_FPOP_FAULT T_FPOPFLT /* coprocessor operand fault */
More generally: Is there any point in supporting these things (subcodes of numeric error signals) at all? AFAICS, they're remainings from the signal handler in ancient versions of the RTS (which had been disabled for a long time). This handler was labeled "BSD style", but if these things are not even supported on FreeBSD, perhaps we should simply drop them. Does any other system support them?
For the SIGILL, I don't think it is worth it. An illegal instruction is an illegal instruction, it isn't going to make much difference to the end user whether it was a privileged instruction or simply an undefined operation. I think many systems define them, but in usually unportable ways.
The SIGFPE error codes are useful though.
Nick.