From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10321 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Regarding whole-archive linking libc.a into a shared lib Date: Thu, 14 Jul 2016 13:43:52 +0200 Message-ID: <20160714114352.GN19691@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1468496652 21443 80.91.229.3 (14 Jul 2016 11:44:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 11:44:12 +0000 (UTC) Cc: Aidan Hobson Sayers To: musl@lists.openwall.com Original-X-From: musl-return-10334-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 14 13:44:11 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bNf3m-0007AL-Pr for gllmg-musl@m.gmane.org; Thu, 14 Jul 2016 13:44:06 +0200 Original-Received: (qmail 1672 invoked by uid 550); 14 Jul 2016 11:44:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1651 invoked from network); 14 Jul 2016 11:44:04 -0000 Mail-Followup-To: musl@lists.openwall.com, Aidan Hobson Sayers Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:10321 Archived-At: * Jason Ramapuram [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.