mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Luca Barbato <lu_zero@gentoo.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
Date: Thu, 26 Jul 2012 00:19:27 +0200	[thread overview]
Message-ID: <501070EF.5000003@gentoo.org> (raw)
In-Reply-To: <20120725150658.GP544@brightrain.aerifal.cx>

On 07/25/2012 05:06 PM, Rich Felker wrote:
> On Tue, Jul 24, 2012 at 11:00:54PM -0400, idunham@lavabit.com wrote:
>> Rich:
>> I have three questions:
>>
>> 1. Should it be possible to weak_alias an externally defined function?
>> ie, src/stdlib/strtod.c defines strtod, then src/glibc-abi/stdlib.c goes:
>> #include "libc.h"
>> #include <stdlib.h>
>> weak_alias(strtod, __strtod_internal)
> 
> This is not possible the way traditional assemblers/linkers work. You
> can make a wrapper function but that adds bloat and has a runtime
> performance cost if the wrapper is used.

The only way I can see to keep them apart of the code is moving them in
an header and conditionally include them when compatibility is enabled
at builtime. Not sure if it would worth it.

>> 3. Would a subdirectory of src/ solely for glibc ABI/API compatability be
>> appropriate?
>> The point would be to allow removing gnuish extensions without too much
>> trouble.
>> Even if 1 or 2 mean that weak_alias stuff goes in the same file, this
>> could contain functions like the ones added for gnulib (src/stdio/ext*.c).
> 
> I think that's confusing matters. The ones added for gnulib are not
> for glibc compatibility; glibc does not even have them. They're added
> so that gnulib will not attempt to poke at musl internals and generate
> musl-version-specific binaries which would crash on different musl
> versions. Removing them is a very bad idea. Moreover on i386 they're
> 55 bytes of code. Removing something like that for space savings is on
> the same order of ridiculousness as some of busybox's optimizations...

And probably leaving a note for the poor soul really needing to shave
those last 55/100 bytes would be enough.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero



  reply	other threads:[~2012-07-25 22:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-25  3:00 idunham
2012-07-25 15:06 ` Rich Felker
2012-07-25 22:19   ` Luca Barbato [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-07-23  1:13 [PATCH 1/10] ioperm & iopl Isaac Dunham
2012-07-23  1:38 ` [PATCH 9/10] GLIBC ABI patches Isaac Dunham
2012-07-23 15:11   ` Arvid E. Picciani
2012-07-24 18:15     ` Igmar Palsenberg
2012-07-24 18:19       ` Gregor Richards
2012-07-24 18:23         ` Igmar Palsenberg
2012-07-24 18:29           ` Gregor Richards
2012-07-24 18:33             ` Igmar Palsenberg
2012-07-24 23:18               ` Rich Felker
2012-07-25  7:27               ` Arvid E. Picciani
2012-07-25 14:12   ` Luca Barbato
2012-07-25 15:19     ` Rich Felker
2012-07-25 15:52       ` Luca Barbato
2012-07-25 17:35         ` Rich Felker
2012-07-25 23:06       ` idunham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=501070EF.5000003@gentoo.org \
    --to=lu_zero@gentoo.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).