From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/912 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: A little more progress today with clang/LLVM Date: Fri, 25 May 2012 19:09:38 -0400 Message-ID: <20120525230938.GZ163@brightrain.aerifal.cx> References: <6099278.PLLg0Rc9Yf@main.pennware.com> <20120522015935.GQ163@brightrain.aerifal.cx> <4664782.yKXjK5ZdZo@main.pennware.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1337987692 3335 80.91.229.3 (25 May 2012 23:14:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 May 2012 23:14:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-913-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 26 01:14:52 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SY3ia-000076-Hq for gllmg-musl@plane.gmane.org; Sat, 26 May 2012 01:14:48 +0200 Original-Received: (qmail 17930 invoked by uid 550); 25 May 2012 23:14:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17919 invoked from network); 25 May 2012 23:14:47 -0000 Content-Disposition: inline In-Reply-To: <4664782.yKXjK5ZdZo@main.pennware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:912 Archived-At: On Fri, May 25, 2012 at 01:56:56PM -0500, Richard Pennington wrote: > I've done a little hacking on alltypes.h.sh which I'm in the process of > testing. I have two goals: > 1. Make it work with clang's headers. Can you explain what the issue is? Are you talking about issues building clang itself, or building programs against musl using clang? In the latter case, musl does not use or support using compiler-provided headers. All of the standard headers are provided fully by musl. > 2. Make it slightly easier to add additional processor support by having > a single alltypes.h for all processors. > > Does this look like I'm going down a reasonable path? No, what you've done is taken header files that work with ANY compiler meeting the target ABI and that are optimized to avoid unnecessary runtime checks, and made them so that they only work with compilers which define particular macros for the name of the target arch and which go through a lot of unnecessary extra conditional tests. Part of the (admittedly not documented anywhere) philosophy of musl's headers is that they should avoid preprocessor conditionals in the headers for "parameters" that are actually constant. > #if defined(__clang__) > TYPEDEF __typeof__(sizeof(int)) size_t; > #else > TYPEDEF unsigned long size_t; > #endif The #else is actually wrong. The i386 ABI uses unsigned int, not unsigned long, for size_t. It's stupid, but it matters because even though the representations and range of values are identical, the types unsigned long * and unsigned int * are not compatible. Also, it breaks C++ name mangling if you use the wrong type. Is clang using different types than gcc for size_t? If so, it means it's impossible to have a shared C++ ABI between the two. If not, what's the problem with the current definition? > #if defined(__clang__) > TYPEDEF __typeof__(((int*)0)-((int*)0)) ptrdiff_t; > #else > #if defined(__x86_64__) || defined(__arm__) || defined(__i386__) > TYPEDEF long ptrdiff_t; > #else > #error ptrdiff_t is not defined for this processor > #endif > #endif One thing that _would_ work for these __typeof__ cases is to put it under __GNUC__, which encompasses ALL compilers that have "GNU C" extensions like typeof. That would definitely be an acceptable change, but unless there are any compilers where it's necessary, I'd rather just leave the types explicit for the arch's ABI. One of the most frustrating things with glibc headers is never being able to figure out the actual underlying definition of a type, and I'd like not to recreate that frustration. > TYPEDEF __builtin_va_list va_list; This does not work with some older compilers if I remember correctly. That's why it's conditional on i386 in the current version. A couple things I'm _NOT_ happy about in my current system are that the whole alltypes.h gets parsed again and again even (for each header that includes it) even if only a few types are needed each time. One thing I'm considering (but not yet decided on) is dropping it and instead having the build system generate all the headers from templates when musl is built, and put the expanded TYPEDEF templates right in the headers that use them. In any case, for now don't worry about the potential ugliness/duplication in alltypes.h.sh for new archs. It's not a large file (the bits/*.h headers are much worse when it comes to duplication) and I'm happy to take responsibility for cleaning them all up later if a better system is devised. Rich