[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Jul 2012 11:06:58 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 9/10] GLIBC ABI patches
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.
> 2. Would this result in obfustication of the source?
I'm not sure.
> 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...
Rich
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.
