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.