From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5861 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: va_list (was: [musl] compiling musl on x86_64 linux with pcc) Date: Fri, 15 Aug 2014 12:49:36 +0200 Message-ID: <20140815104936.GA5170@example.net> References: <20140813091843.GD5170@example.net> <20140813123832.GK12888@brightrain.aerifal.cx> <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> 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 1408099802 26414 80.91.229.3 (15 Aug 2014 10:50:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 10:50:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5867-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 15 12:49:57 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 1XIF53-0007lB-F2 for gllmg-musl@plane.gmane.org; Fri, 15 Aug 2014 12:49:57 +0200 Original-Received: (qmail 13614 invoked by uid 550); 15 Aug 2014 10:49:56 -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 13606 invoked from network); 15 Aug 2014 10:49:56 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe03.swip.net; client-ip=78.46.51.124; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140814144702.GZ12888@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5861 Archived-At: 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