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.