[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140827075407.GL12888@brightrain.aerifal.cx>
Date: Wed, 27 Aug 2014 03:54:07 -0400
From: Rich Felker <dalias@...c.org>
To: u-igbb@...ey.se
Cc: musl@...ts.openwall.com
Subject: Re: compiling musl on x86_64 linux with pcc
On Wed, Aug 27, 2014 at 09:40:36AM +0200, u-igbb@...ey.se wrote:
> > in fact, as I explained before, there is only one correct
> > implementation: builtin functions like __builtin_va_arg, etc. but
> > possibly with gratuitously different names or argument orders. In any
> > case there is no way to simply "let the compiler do it" because
> > certain other headers need to access or expose the va_list type, and
> > doing this with a compiler-provided stdarg.h requires knowledge of the
> > compiler versions internals in the libc headers, which is much worse
> > than the current situation.
>
> The current situation is (!) actually using knowledge of the compiler
> in the library headers (checking for gcc version, as you noted when we
> were talking about tcc), which shouldn't be needed if the library would
> skip referring to the intimate knowledge of those details.
This is only a hack that's left in the i386 headers for supporting
ancient gcc versions that probably have not worked right for more than
a decade. It should probably be removed, and bits/stdarg.h removed.
> I am possibly not realizing some crucial bit but I do not see why the
> implementation of stdarg.h must be the business of the library. If the
Because other headers need to know how to get va_list defined for use
in function prototypes, and they can't include stdarg.h because it
would expose more than they want. glibc handles this by making use of
a special inclusion protocol between the glibc headers and the gcc
headers: it defines a special macro before including stdarg.h telling
gcc that it just wants the definition of va_list and nothing else.
> compiler *building* the library wants the va_arg to be __builtin_va_arg,
> then you get the same functionality / efficiency as now, otherwise you
> get a less efficient but still fully compatible library, don't you?
No. This has absolutely nothing to do with efficiency.
> A compiler used *together* with the library may lack the builtins but it
> still can be fully compatible even if in some situations less efficient.
No, it can't. There is simply no way to express, in C, the concept of
"get the next variadic argument" without __builtin_va_arg or something
100% equivalent to it. If you have a compiler than chooses to be
gratuitously incompatible and use a different name for its builtin,
you can always add -D'__builtin_va_arg(x)=__foo(x)' etc. to your
CFLAGS when using that compiler. However no such compiler seems to
exist.
> No compiler (if ABI-compatible) is allowed to produce code unusable when
> linked to code compiled by another compiler. How allowing the compiler
> to pick its own stdarg.h would lead to a less efficient code than otherwise?
Again, this has nothing to do with ABI between external variadic
functions. It's a matter of the inability to express to the compiler
what you want it to do (get the next variadic argument) in plain C.
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.
