The following reply was made to PR kern/158418; it has been noted by GNATS.
From: Alan Larson <[email protected]> To: [email protected], [email protected] Cc: [email protected], [email protected] Subject: Re: misc/158418: /usr/include librarys broken by unnecessary extra macro indirection. Date: Thu, 30 Jun 2011 17:14:04 -0700 (PDT) Thanks for your reply. Perhaps I need to clarify a few details. > On Tue, 28 Jun 2011, Alan Larson wrote: > > >> Description: > > > > The macro __aligned(x) is used several places in files in /usr/include, > > but is only > > defined if using a sufficiently new version of GCC, or an Intel compiler. > > The definitions are inside an #if __GNUC_PREREQ__(2, 7) and #if > > defined(__INTEL_COMPILER) > > > > This breaks things when compiled with PCC or TCC. ( > > http://pcc.ludd.ltu.se/jira/browse/PCC-18 ) > > Unfortunately, breaking is the correct behaviour since the ABI depends on > the struct layout, so only compilers that support packing and alignment > can work. Structs should be layed out more carefully so that packing and > alignment directives are never needed, but this is sometimes impossible. Fortunately, both PCC and TCC do support packing and alignment. > >> How-To-Repeat: > > > > Attempt to compile something that has an #include <signal.h> with TCC (or > > presumably, PCC). > > > > Inspection of the code indicates that the same problem is true for > > __packed . > > > > Other values are also redefined in those same conditionals, and they > > probably have > > the same problems. > > The problem outside the kernel doesn't seem to affect much more than > <signal.h>, though relatively recently it has spread to some networking > headers, especially ipv6 ones. > > Two likely fixes come to mind: > > > > 1. Don't use these macro shortcuts, use the __attribute__ form > > directly. > > Many of the files in /usr/include do this, so fixing the remaining > > ones > > would simplify things. It should only take a few minutes to fix > > them. > > There are still lots of places using the __attribute__ form, so this > > is a proven safe and reasonable solution. > > That would enlarge the bug. Doing it for an old version of tcc -Ysystem > gives: > > % "/usr/include/machine/signal.h", line 122: Error: > % [Syntax]: Parse error before '__attribute__'. > % [Syntax]: Can't recover from this error. > > since old versions of tcc don't support __attribute__ any more than they > support the newer types of attributes like the one for alignment. This is actually not a problem, or at least not *the* problem. tcc supports these __attribute__ options, and in the many cases where they are used without the conditional definitions, is happy with them. I checked with the November 2004 version 0.9.22 of tcc. > The macros are not just shortcuts, but exist primarily to avoid hard-coding > gccisms like __attribute__ in lots of places. Well, it seemed easier than including the macos for every possible compiler, but if you prefer, please add this to sys/cdefs.h #ifdef __TINYC__ #define __dead2 __attribute__((__noreturn__)) #define __pure2 __attribute__((__const__)) #define __unused __attribute__((__unused__)) #define __used __attribute__((__used__)) #define __packed __attribute__((__packed__)) #define __aligned(x) __attribute__((__aligned__(x))) #define __section(x) __attribute__((__section__(x))) #endif Actually, it may make more sense to just define them unless you know the compiler cannot handle them, and it would probably be a shorter .h file, too. Alan p.s. is there are reason that the intel compiler version says #define<space>__blah while the GCC one says #define<tab>_blah ? As you can see, I used the tab version because I know that worked with TINYC. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
