From owner-freebsd-bugs@FreeBSD.ORG Fri Jul 1 00:33:42 2011 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5640A1065672 for ; Fri, 1 Jul 2011 00:33:42 +0000 (UTC) (envelope-from larson@w6yx.stanford.edu) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0DD8FC12 for ; Fri, 1 Jul 2011 00:33:42 +0000 (UTC) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 85CEA804B; Thu, 30 Jun 2011 17:14:10 -0700 (PDT) Received: from w6yx.stanford.edu (w6yx.Stanford.EDU [171.67.193.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id EB2BA812E; Thu, 30 Jun 2011 17:14:09 -0700 (PDT) Received: from w6yx.stanford.edu (localhost [127.0.0.1]) by w6yx.stanford.edu (8.14.4/8.14.4) with ESMTP id p610E441065530; Thu, 30 Jun 2011 17:14:09 -0700 (PDT) (envelope-from larson@w6yx.stanford.edu) Received: (from larson@localhost) by w6yx.stanford.edu (8.14.4/8.14.4/Submit) id p610E4Rn065529; Thu, 30 Jun 2011 17:14:04 -0700 (PDT) (envelope-from larson) Date: Thu, 30 Jun 2011 17:14:04 -0700 (PDT) From: Alan Larson Message-Id: <201107010014.p610E4Rn065529@w6yx.stanford.edu> To: brde@optusnet.com.au, larson@w6yx.stanford.edu In-Reply-To: <20110630093231.L1117@besplex.bde.org> Cc: freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/158418: /usr/include librarys broken by unnecessary extra macro indirection. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 00:33:42 -0000 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 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 > , 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__blah while the GCC one says #define_blah ? As you can see, I used the tab version because I know that worked with TINYC.