misc/158418: /usr/include librarys broken by unnecessary extra
larson at w6yx.stanford.edu
Fri Jul 1 00:20:07 UTC 2011
The following reply was made to PR kern/158418; it has been noted by GNATS.
From: Alan Larson <larson at w6yx.stanford.edu>
To: brde at optusnet.com.au, larson at w6yx.stanford.edu
Cc: freebsd-bugs at freebsd.org, FreeBSD-gnats-submit at freebsd.org
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
> % "/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
#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)))
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.
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.
More information about the freebsd-bugs