[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Aug 2014 19:12:31 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: va_list (was: compiling musl on x86_64 linux with
pcc)
On Fri, Aug 15, 2014 at 11:56:56AM -0400, Rich Felker wrote:
> > Testing... I can compile with tcc a file calling printf, link
> > with musl and successfully run it. Nice!
> >
> > (Hmm, bits/alltypes defines ...va_list "instead of including stdarg.h",
> > I guess it could be made to include, guarded by some #if defined() ?
>
> No, this is the nasty gcc way which precludes the compiler from
> optimizing out multiple inclusions of the same header file, and which
> requires the libc headers and headers provided by the compiler to be
> aware of each other's implementation details, which is not really
> appropriate.
Fine with me, it is just a matter to teach tcc to implicitly include its
stdarg.h.
> > Besides this detail, it was apparently just a matter of wrapping tcc
> > with "-I<where-the-tcc-stdarg.h-alone-lives> \
> > -D__DEFINED_va_list \
> > -D__isoc_va_list=va_list \
> > -D__DEFINED___isoc_va_list"
> > (this part is of course not of concern for musl, besides preserving the
> > possibility to externally define the types, in a compiler-specific stdarg.h)
>
> This is not supported usage with musl.
Surely, I am using the internal details which is bad - it would be
nice if musl would allow a cleaner way of doing a corresponding
hook.
> > I think this is a correct approach which makes musl usable with
> > more compilers than otherwise.
>
> Only tcc, and tcc really just needs to be fixed in this regard. All
This of course would be the best solution - but tcc is as it is, with
the limitations and the nice properties. I'd like to be able to use it,
or if anybody hacks a differently nice / differently bad compiler,
to be able to use it too.
This does not look like putting any constraints on musl efficienly or
correctness - the only thing which is necessary is a (possibly even
musl-version-dependent) way to skip/replace the va-definitions. I think
it is no practical problem, good enough, unless you decide to radically
change the implementation.
> the other compilers do it right already. It would not be hard to add
> the builtins and have them do the right thing, and this is essentially
> needed for x86_64 anyway -- the current approach of calling external
> functions is totally inappropriate since the generated .o files are
> not compatible with the ABI (which does not define such external
> functions) and cannot be successfully linked by non-tcc toolchains.
Hmm. Yes that's right (non-tcc-"aware" toolchains that is - no problem
to arrange non-tcc linking to work, but you can not give such object files
to others to link...). To be compatible, a compiler-specific implementation
must be effectively inlined in every .o file, which tcc does not do
(and which builtins of course do, but they are nevertheless not the only
valid solution - even though they seem to be a good one :)
Thanks for clearing the matter!
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.
