[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160714114352.GN19691@port70.net>
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.
