From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5865 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: va_list (was: [musl] compiling musl on x86_64 linux with pcc) Date: Fri, 15 Aug 2014 19:12:31 +0200 Message-ID: <20140815171231.GE5170@example.net> References: <20140813125607.GK5170@example.net> <20140813142332.GN12888@brightrain.aerifal.cx> <20140814071055.GN5170@example.net> <20140814142056.GX12888@brightrain.aerifal.cx> <20140814143838.GR5170@example.net> <20140814144702.GZ12888@brightrain.aerifal.cx> <20140815104936.GA5170@example.net> <20140815134434.GP12888@brightrain.aerifal.cx> <20140815150722.GC5170@example.net> <20140815155656.GQ12888@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1408122781 24972 80.91.229.3 (15 Aug 2014 17:13:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 17:13:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5871-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 15 19:12:53 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XIL3c-0005BA-A6 for gllmg-musl@plane.gmane.org; Fri, 15 Aug 2014 19:12:52 +0200 Original-Received: (qmail 7431 invoked by uid 550); 15 Aug 2014 17:12:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7421 invoked from network); 15 Aug 2014 17:12:50 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=77.109.139.87; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140815155656.GQ12888@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5865 Archived-At: 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 \ > > -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