Date: Thu, 14 Jul 2016 13:43:52 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Cc: Aidan Hobson Sayers <aidanphs@...il.com> Subject: Re: Regarding whole-archive linking libc.a into a shared lib * Jason Ramapuram <jason.ramapuram@...il.com> [2016-07-14 12:49:31 +0200]: > Thanks for the link. Just went through the entire thread. I think we can > solve the problems as such though: > > 1. Have some form of linker that mangles all the symbols internally in > the newly linked shared library, eg: FILE* --> FILE_mangled* so that > internally it has it's own libc calls that are independent from anything > that a binary might require. > 2. Block allocate a chunk of memory internally in the library so that > allocations are now using that internal block and not malloc-ing. > > However, I'm not quite sure how 1) could be solved at this time. > 1) libc maintains global state which will be duplicated in your shared lib (e.g. envvars, stdio buffers, timezone, locales) name mangling does not fix their behaviour (they will behave inconsistently with other parts of the application). 2) brk is not the only global state that can only have one owner, the thread pointer is another example: if your shared lib does any tls access (e.g. errno, stack canary) then it has to match the internals of the libc in the main application (won't work across libc versions). static linking libc into a shared lib simply does not make sense.
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.