From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5084 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Linking musl with ld.gold Date: Wed, 7 May 2014 23:01:03 -0400 Message-ID: <20140508030102.GF26358@brightrain.aerifal.cx> References: <20140506101410.GP12324@port70.net> <20140506231807.GQ12324@port70.net> <20140507130443.72c74f47@vostro> <20140508010605.GE26358@brightrain.aerifal.cx> 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 1399518083 6134 80.91.229.3 (8 May 2014 03:01:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 03:01:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5090-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 05:01:17 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WiEaB-00048x-LP for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 05:01:15 +0200 Original-Received: (qmail 18419 invoked by uid 550); 8 May 2014 03:01:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18411 invoked from network); 8 May 2014 03:01:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5084 Archived-At: On Thu, May 08, 2014 at 03:08:41AM +0100, Stephen Thomas wrote: > > On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote: > > > On Wed, 7 May 2014 10:04:24 +0100 > > > Stephen Thomas wrote: > > > > > > > > only the object files with referenced symbols are linked from an > > > > > archive > > > > > > > > > > so only a.o with the given main.o because of the symbol f > > > > > > > > > > now if you make some reference in main.c such that b.o should > > > > > be included but main still returns 0 that would be a bug > > > > > > > > > > eg. add a void g(void){} to b.c and call it from main.c > > > > > > > > Ok, thanks for that info. It appears that there is a problem in gcc > > > > 4.9 and not 4.8.3. > > > > > > Is perhaps -ffunction-sections and/or -fdata-sections added > > > automatically? Those would break musl like experienced. > > > > They should not break musl; if they do, it's a compiler bug. The > > strong symbol that overrides the weak symbol elsewhere is not unused > > and available for garbage collection because it's referenced. > > > > I suspect your claim is just wrong, since IIRC people have > > successfully used these options with musl. > > I will raise an issue with the gcc team (but I don't really want to > build from git, as it takes too long). I am not saying that the > library doesn't work, I am merely saying that there was a bug where > stdout was not being flushed, and this in my opinion was due to the > weak symbol in fflush not being overridden. I did run that single > test case on the two different builds and the result was different. > This was on two clean buildroot branches based on uclibc. My reply to Timo was not in doubt that you observed such an issue, but rather expressing doubt about his possible explanation. I don't think it has anything to do with -ffunction-sections or -fdata-sections. > I don't understand what you mean by garbage collection. Basically, Those two options are meant to be used with the linker option --gc-sections, which performs garbage collection to remove any sections which are not referenced. > if I understand this correctly, there is a weak symbol defined in > fflush.c for the purpose of allowing this file to run without the an > implementation that initialises the real symbol with the internal > implementation of stdout (which is just basically a manufactured > wrapper around file descriptor number 1). This is good as far as > unit testing goes, doesn't use #defines but the linker -- good > stuff. However, when I noticed was that the prompt on busybox using > musl was not appearing until after a new line was entered, I added a > discovered that the value of the pointer was 0 (NULL). If you still > suspect that my claim is wrong, then I believe you are saying that I'm just saying Timo's claim about the mechanism of what you observed is probably wrong. The way the 'magic' with weak symbols work is that the weak definition satisfies the reference, so that the linker does not need to pull in additional object files to satisfy it. But once an additional file which has a strong definition is pulled in (as a result of another undefined symbol reference), the strong definition is _referenced_ (because it overrides any weak definitions) and thus its section is not a legal candidate for garbage collection via --gc-sections. > this is not the case. It would be nice if someone who has gcc 4.9 > installed could run either run the test or check that busybox is > working. The bug is almost surely in the linker, not gcc, unless it's a matter of gcc passing bad options to the linker. You can add -v to the gcc command line for linking to see exactly how it invokes the linker. Rich