[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 26 Jul 2012 00:19:27 +0200
From: Luca Barbato <lu_zero@...too.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
On 07/25/2012 05:06 PM, Rich Felker wrote:
> On Tue, Jul 24, 2012 at 11:00:54PM -0400, idunham@...abit.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
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.
