[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140815104936.GA5170@example.net>
Date: Fri, 15 Aug 2014 12:49:36 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: va_list (was: compiling musl on x86_64 linux with pcc)
On Thu, Aug 14, 2014 at 10:47:02AM -0400, Rich Felker wrote:
> > > > That's a pity. Wonder whether it would cost too much to make
> > > > __builtin_va_list non-mandatory?
> > >
> > > How else would you do it? There's no real alternative.
To be able to mix object files and/or libraries compiled with different
compilers apparently there must be a standard ABI.
This seems also to be reflected in
https://stackoverflow.com/questions/4958384/what-is-the-format-of-the-x86-64-va-list-structure
and (referred from there)
http://www.x86-64.org/documentation/abi.pdf
I may be missing something but it looks like this ABI can not be an opaque
fully "compiler's internal business". Compilers may implement as much
optimizations as they wish but they must be able to produce interoperable
object files, don't they?
I would appreciate to be enlightened on this matter, what is the obstacle
to adding a compiler-independent definition of va_list (or otherwise
possibly even using the compiler-specific non-builtin definition, like
the one of tcc)?
This of course does not have to be used when the presumably more efficient
builtin is available.
Rune
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.
