Date: Thu, 30 Jun 2011 17:14:04 -0700 (PDT) From: Alan Larson <larson@w6yx.stanford.edu> To: brde@optusnet.com.au, larson@w6yx.stanford.edu Cc: freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/158418: /usr/include librarys broken by unnecessary extra macro indirection. Message-ID: <201107010014.p610E4Rn065529@w6yx.stanford.edu> In-Reply-To: <20110630093231.L1117@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107010014.p610E4Rn065529>