[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120525230938.GZ163@brightrain.aerifal.cx>
Date: Fri, 25 May 2012 19:09:38 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: A little more progress today with clang/LLVM
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
