0000000000000000 V hasfoo

b.o:

0000000000000000 d foo

00000= 00000000000 R hasfoo

********************************************= ****************

Case 3: 0

****************************= ********************************

=3B

>=3B Date= : Tue=2C 6 May 2014 12:14:10 +0200
>=3B From: nsz@port70.net
>=3B= To: musl@lists.openwall.com
>=3B Subject: Re: [musl] Linking musl wit= h ld.gold
>=3B
>=3B * Stephen Thomas <=3Bscjthm@live.com>=3B= [2014-05-06 10:07:59 +0100]:
>=3B >=3B I have come across a problem= and it only appears when the gold linker is used. I am using the latest re= lease of binutils=2C binutils-2.24.51.0.3.
>=3B >=3B I discovered th= at busybox was not flushing stdout (as there was no prompt appearing) when = using musl. Busybox calls fflush(NULL) which should flush stdout as done in= src/stdio/fflush.c.
>=3B >=3B In that file I checked the value for= __stdout_used and it came back as 0. So I changed the declaration of the w= eak symbol to an extern FILE* __stdout_used and stdout was being flushed.>=3B >=3B Has anyone else seen this and have they reported this appar= ent bug in binutils?
>=3B
>=3B
>=3B i think we only report= ed a broken tls visibility issue against gold
>=3B https://sourceware.= org/bugzilla/show_bug.cgi?id=3D16728
>=3B
>=3B you should try to= reproduce the bug on a minimal example=2C eg. the
>=3B following code= works here with gold (binutils 2.22)
>=3B
>=3B // a.c
>=3B= struct foo {int i=3B}=3B
>=3B static struct foo *const dummy =3D 0=3B=
>=3B extern struct foo *const hasfoo __attribute__((weak=2C alias("du= mmy")))=3B
>=3B int f(void)
>=3B {
>=3B return hasfo= o ? hasfoo->=3Bi : 0=3B
>=3B }
>=3B // b.c
>=3B struct foo= {int i=3B}=3B
>=3B static struct foo foo =3D {42}=3B
>=3B struct= foo *const hasfoo =3D &=3Bfoo=3B
>=3B // main.c
>=3B int f(vo= id)=3B
>=3B int main()
>=3B {
>=3B return f()=3B
= >=3B }
>=3B
>=3B gcc main.o a.o -o t1
>=3B gcc main.o a.o= b.o -o t2
>=3B ./t1 returns 0
>=3B ./t2 returns 42

= --_89c885d4-a08f-43d0-b3bd-5c03c4d321e1_-- --_e85b9571-00a8-4cd9-ae68-216533227a15_ Content-Type: application/x-sh Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="badar.sh" IyEvYmluL3NoIC1lCkFSPWFyCk5NPW5tCkNDPWdjYwpDRkxBR1M9IiIKI3VzZSBnY2MtYXIgYW5k IGdjYy1ubSB3aGVuIHVzaW5nIC1mbHRvIC1mdXNlLWxpbmtlci1wbHVnaW4iCkZMSVNUPSJhLmMg Yi5jIG1haW4uYyBhLm8gYi5vIG1haW4ubyBhLmEgYSIKY2QgL3RtcAppZiBbICIkKGxzIC1sICR7 RkxJU1R9IDI+IC9kZXYvbnVsbCB8IHdjIC1sKSIgIT0gIjAiIF0gOyB0aGVuCiAgICBlY2hvICJT b3JyeSBvbmUgb2YgdGhlc2UgZmlsZXMgZXhpc3RzICR7RkxJU1R9IGFuZCBJIHdvdWxkIGxpa2Ug dG8gb3ZlcndyaXRlIHRoZW0iCiAgICBleGl0IDEKZmkKY2F0ID4gYS5jIDw8IF9FT0YKLy8gYS5j CnN0cnVjdCBmb28ge2ludCBpO307CnN0YXRpYyBzdHJ1Y3QgZm9vICpjb25zdCBkdW1teSA9IDA7 CmV4dGVybiBzdHJ1Y3QgZm9vICpjb25zdCBoYXNmb28gX19hdHRyaWJ1dGVfXygod2VhaywgYWxp YXMoImR1bW15IikpKTsKaW50IGYodm9pZCkKewogICAgcmV0dXJuIGhhc2ZvbyA/IGhhc2Zvby0+ aSA6IDA7Cn0KX0VPRgpjYXQgPiBiLmMgPDwgX0VPRgovLyBiLmMKc3RydWN0IGZvbyB7aW50IGk7 fTsKc3RhdGljIHN0cnVjdCBmb28gZm9vID0gezQyfTsKc3RydWN0IGZvbyAqY29uc3QgaGFzZm9v ID0gJmZvbzsKX0VPRgpjYXQgPiBtYWluLmMgPDwgX0VPRgovLyBtYWluLmMKaW50IGYodm9pZCk7 CmludCBtYWluKCkKewogICAgcmV0dXJuIGYoKTsKfQpfRU9GCiR7Q0N9ICR7Q0ZMQUdTfSAtYyBh LmMKJHtDQ30gJHtDRkxBR1N9IC1jIGIuYwoke0NDfSAke0NGTEFHU30gLWMgbWFpbi5jCiR7Q0N9 ICR7Q0ZMQUdTfSAtbyBhIG1haW4ubyBhLm8KZWNobyAiKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIgplY2hvICJSdW5uaW5nIHdpdGgg Li4uIgpnY2MgLS12ZXJzaW9uCmxkIC0tdmVyc2lvbgplY2hvICIqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioiCnJldD0wCi4vYSB8fCBy ZXQ9JHs/fQplY2hvICJDYXNlIDA6ICR7cmV0fSIKZWNobyAiKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIgpybSAtZiBhLmEgYQoke0ND fSAke0NGTEFHU30gLW8gYSBtYWluLm8gYS5vIGIubwplY2hvICIqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioiCnJldD0wCi4vYSB8fCBy ZXQ9JHs/fQplY2hvICJDYXNlIDE6ICR7cmV0fSIKZWNobyAiKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIgpybSAtZiBhLmEgYQoke0FS fSByIGEuYSBhLm8KJHtOTX0gYS5hCiR7Q0N9ICR7Q0ZMQUdTfSAtbyBhIG1haW4ubyBhLmEKZWNo byAiKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqIgpyZXQ9MAouL2EgfHwgcmV0PSR7P30KZWNobyAiQ2FzZSAyOiAke3JldH0iCmVjaG8g IioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiIKcm0gLWYgYS5hIGEKJHtBUn0gciBhLmEgYS5vIGIubwoke05NfSBhLmEKJHtDQ30gJHtD RkxBR1N9IC1vIGEgbWFpbi5vIGEuYQplY2hvICIqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioiCnJldD0wCi4vYSB8fCByZXQ9JHs/fQpl Y2hvICJDYXNlIDM6ICR7cmV0fSIKZWNobyAiKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIgpybSAtZiBhLmMgYi5jIG1haW4uYyBhLm8g Yi5vIG1haW4ubyBhLmEgYQo= --_e85b9571-00a8-4cd9-ae68-216533227a15_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5066 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Linking musl with ld.gold Date: Wed, 7 May 2014 01:18:08 +0200 Message-ID: <20140506231807.GQ12324@port70.net> References: <20140506101410.GP12324@port70.net> 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 1399418309 28790 80.91.229.3 (6 May 2014 23:18:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 May 2014 23:18:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5072-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 07 01:18:22 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 1Whocv-0005YX-3t for gllmg-musl@plane.gmane.org; Wed, 07 May 2014 01:18:21 +0200 Original-Received: (qmail 7245 invoked by uid 550); 6 May 2014 23:18:20 -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 7235 invoked from network); 6 May 2014 23:18:19 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5066 Archived-At: * Stephen Thomas [2014-05-06 22:11:32 +0100]: > I think that I have managed to reproduce the problem, in as much isolation as possible. I believe that there is a missing step in your test, which is included in the build, and that is the creation of the archive. I may have done something incorrect also, which is also very likely. > I attach a simple script for running the tests on my machine. Unfortunately, the system I use doesn't display indicate where ld.gold was being used as it chooses to do this by changing the symlink to which ld points to. > To summari(s/z)e when using ar to create an archive the weak symbol doesn't appear to be overridden, using either ld.bfd nor ld.gold. The script that was used to generate the output is attached and this should describe the 4 test cases. Test case #2 is probably irrelevant, and the first two are simply reproducing the results of your tests. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5073 Path: news.gmane.org!not-for-mail From: Stephen Thomas Newsgroups: gmane.linux.lib.musl.general Subject: RE: Linking musl with ld.gold Date: Wed, 7 May 2014 10:04:24 +0100 Message-ID: References: ,<20140506101410.GP12324@port70.net>,,<20140506231807.GQ12324@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_530eb34f-7d8b-4b86-a532-94970ad46a5c_" X-Trace: ger.gmane.org 1399453485 20114 80.91.229.3 (7 May 2014 09:04:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 May 2014 09:04:45 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-5079-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 07 11:04:39 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 1WhxmJ-0003Pp-1L for gllmg-musl@plane.gmane.org; Wed, 07 May 2014 11:04:39 +0200 Original-Received: (qmail 30540 invoked by uid 550); 7 May 2014 09:04:37 -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 30527 invoked from network); 7 May 2014 09:04:36 -0000 X-TMN: [x7OI5dVwDWMVq1gX45mJbElznkfJZ04T] X-Originating-Email: [scjthm@live.com] Importance: Normal In-Reply-To: <20140506231807.GQ12324@port70.net> X-OriginalArrivalTime: 07 May 2014 09:04:24.0456 (UTC) FILETIME=[5787B080:01CF69D3] Xref: news.gmane.org gmane.linux.lib.musl.general:5073 Archived-At: --_530eb34f-7d8b-4b86-a532-94970ad46a5c_ Content-Type: multipart/alternative; boundary="_0bdbb9b0-899e-46ee-abe1-52baf5d7806e_" --_0bdbb9b0-899e-46ee-abe1-52baf5d7806e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=20 > only the object files with referenced symbols are linked from an archive >=20 > so only a.o with the given main.o because of the symbol f >=20 > 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 >=20 > eg. add a void g(void){} to b.c and call it from main.c Ok=2C thanks for that info. It appears that there is a problem in gcc 4.9 a= nd not 4.8.3. Come to think of it this I only noticed the prompt being wron= g when using gcc 4.9. I will check this with the git version of gcc also. = I attach the code also. This is from 4.8***********************************************************= *Running with ...gcc (Gentoo 4.8.2-r1 p1.4-ssptest=2C pie-0.5.9-ssptest) 4.= 8.2Copyright (C) 2013 Free Software Foundation=2C Inc.This is free software= =3B see the source for copying conditions. There is NOwarranty=3B not even= for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Case A: 42************************************************************ar: c= reating a.a a.o:0000000000000000 r dummy0000000000000000 T f0000000000000000 V hasfoo b.o:0000000000000000 d foo0000000000000000 T g0000000000000000 R hasfooCase= B: 42************************************************************ and this is from 4.9*******************************************************= *****Running with ...x86_64-buildroot-linux-musl-gcc (Buildroot 2014.05-git= -00965-gf077df0-dirty) 4.9.0Copyright (C) 2014 Free Software Foundation=2C = Inc.This is free software=3B see the source for copying conditions. There = is NOwarranty=3B not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR P= URPOSE. Case A: 0************************************************************ar: cr= eating a.a a.o:0000000000000000 r dummy0000000000000000 T f0000000000000000 V hasfoo b.o:0000000000000000 d foo0000000000000000 T g0000000000000000 R hasfooCase= B: 0************************************************************ = --_0bdbb9b0-899e-46ee-abe1-52baf5d7806e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B
>=3B only the = object files with referenced symbols are linked from an archive
>=3B <= br>>=3B so only a.o with the given main.o because of the symbol f
>= =3B
>=3B now if you make some reference in main.c such that b.o shoul= d
>=3B be included but main still returns 0 that would be a bug
>= =3B
>=3B eg. add a void g(void){} to b.c and call it from main.c
<= /div>

Ok=2C thanks for that info. It appears that there = is a problem in gcc 4.9 and not 4.8.3. Come to think of it this I only noti= ced the prompt being wrong when using =3Bgcc 4.9. I will check this wi= th the git version of gcc also. I attach the code also.

This is from 4.8

*************************************= ***********************

Running with ...

gcc (Gentoo 4.= 8.2-r1 p1.4-ssptest=2C pie-0.5.9-ssptest) 4.8.2

This is free software=3B see t= he source for copying conditions. =3BThere is NO

warranty=3B= not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Case A: 42

*************************************= ***********************

ar: creating a.a

a.o:

0000000000000000 r dummy

0000000000000000 T f

0000000000000000 V hasfoo

b.o:

00= 00000000000000 d foo

0000000000000000 T g

0000000000000= 000 R hasfoo

Case B: 42

*******************************= *****************************

and this is fr= om 4.9

*****************************************************= *******

Running with ...

x86_64-buildroot-linux-musl-gc= c (Buildroot 2014.05-git-00965-gf077df0-dirty) 4.9.0

This is free software=3B = see the source for copying conditions. =3BThere is NO

warran= ty=3B not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Case A: 0

*********************************= ***************************

ar: creating a.a

a.o:

0000000000000000 r dummy

0000000000000000 T f=

0000000000000000 V hasfoo

b.o:

0000000000000000 d foo

0000000000000000 T g

000000000= 0000000 R hasfoo

Case B: 0

****************************= ********************************

= --_0bdbb9b0-899e-46ee-abe1-52baf5d7806e_-- --_530eb34f-7d8b-4b86-a532-94970ad46a5c_ Content-Type: application/x-sh Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="badgcc.sh" IyEvYmluL3NoIC1lCkxPQURFUj0iIgpDQz0iZ2NjIgpBUj0iYXIiCk5NPSJubSIKRkxJU1Q9ImEu YyBiLmMgbWFpbi5jIGEubyBiLm8gbWFpbi5vIGEuYSBhIgpjZCAvdG1wCmlmIFsgIiQobHMgLWwg JHtGTElTVH0gMj4gL2Rldi9udWxsIHwgd2MgLWwpIiAhPSAiMCIgXSA7IHRoZW4KICAgIGVjaG8g IlNvcnJ5IG9uZSBvZiB0aGVzZSBmaWxlcyBleGlzdHMgJHtGTElTVH0gYW5kIEkgd291bGQgbGlr ZSB0byBvdmVyd3JpdGUgdGhlbSIKICAgIGV4aXQgMQpmaQpjYXQgPiBhLmMgPDwgX0VPRgovLyBh LmMKc3RydWN0IGZvbyB7aW50IGk7fTsKc3RhdGljIHN0cnVjdCBmb28gKmNvbnN0IGR1bW15ID0g MDsKZXh0ZXJuIHN0cnVjdCBmb28gKmNvbnN0IGhhc2ZvbyBfX2F0dHJpYnV0ZV9fKCh3ZWFrLCBh bGlhcygiZHVtbXkiKSkpOwppbnQgZih2b2lkKQp7CiAgICByZXR1cm4gaGFzZm9vID8gaGFzZm9v LT5pIDogMDsKfQpfRU9GCmNhdCA+IGIuYyA8PCBfRU9GCi8vIGIuYwpzdHJ1Y3QgZm9vIHtpbnQg aTt9OwpzdGF0aWMgc3RydWN0IGZvbyBmb28gPSB7LmkgPSA0Mn07CnN0cnVjdCBmb28gKmNvbnN0 IGhhc2ZvbyA9ICZmb287CnZvaWQgZygpCnsKfQpfRU9GCmNhdCA+IG1haW4uYyA8PCBfRU9GCi8v IG1haW4uYwppbnQgZih2b2lkKTsKdm9pZCBnKCk7CmludCBtYWluKCkKewogICAgZygpOwogICAg cmV0dXJuIGYoKTsKfQpfRU9GCiR7Q0N9ICR7Q0ZMQUdTfSAtYyBhLmMKJHtDQ30gJHtDRkxBR1N9 IC1jIGIuYwoke0NDfSAke0NGTEFHU30gLWMgbWFpbi5jCiR7Q0N9ICR7Q0ZMQUdTfSAtbyBhIG1h aW4ubyBhLm8gYi5vCmVjaG8gIioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiIKZWNobyAiUnVubmluZyB3aXRoIC4uLiIKJHtDQ30gLS12 ZXJzaW9uCiR7Q0N9ICR7Q0ZMQUdTfSAtbyBhIG1haW4ubyBhLm8gYi5vCnJldD0wOyAke0xPQURF Un0gLi9hIHx8IHJldD0kez99CmVjaG8gIkNhc2UgQTogJHtyZXR9IgplY2hvICIqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioiCiR7QVJ9 IHIgYS5hIGEubyBiLm8KJHtOTX0gYS5hCiR7Q0N9ICR7Q0ZMQUdTfSAtbyBhIG1haW4ubyBhLmEK cmV0PTA7ICR7TE9BREVSfSAuL2EgfHwgcmV0PSR7P30KZWNobyAiQ2FzZSBCOiAke3JldH0iCmVj aG8gIioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKiIKZXhpdApybSAtZiAke0ZMSVNUfQo= --_530eb34f-7d8b-4b86-a532-94970ad46a5c_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5076 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Linking musl with ld.gold Date: Wed, 7 May 2014 13:04:43 +0300 Message-ID: <20140507130443.72c74f47@vostro> References: <20140506101410.GP12324@port70.net> <20140506231807.GQ12324@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399457099 10935 80.91.229.3 (7 May 2014 10:04:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 May 2014 10:04:59 +0000 (UTC) Cc: scjthm@live.com To: musl@lists.openwall.com Original-X-From: musl-return-5082-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 07 12:04:48 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 1WhyiV-0003SG-LY for gllmg-musl@plane.gmane.org; Wed, 07 May 2014 12:04:47 +0200 Original-Received: (qmail 28312 invoked by uid 550); 7 May 2014 10:04:46 -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 28304 invoked from network); 7 May 2014 10:04:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=1nyCRq/qbQbStFre4u8J6MdMBnxBBZTM+mfaHCVCmHA=; b=har4G8nJ9VUg6f+1/zaD9H7mmPTIx+Q9rqnsKyFUg/vGt00P0Q1n7z73+gw0LuqN4S jsFXZm1ko/s1r7QM4qDGGlLfeZ4wOf57O4ZIhiTM5rRORN7vMJtdmXwx8DEazYMJJQfs CL14ofYbMtdUKKuZwq1AmnbOoSSomtQlpuh5odJF0izWrXTAcRWBT7pXhr6oW7Bi+RmF MCwRyEfUMPuQYVKziWDs1h63ItseZGZAqmj5E9uuj66SqvOEeRu//0XXKvkP1xUV2C52 w72zbfdiT1Pmpc5aS74hY9P3VaS1lNfRKybNzAJNIhzK7olWpCFkOnJk/J5t+Dxl6jLm Hvxw== X-Received: by 10.112.4.106 with SMTP id j10mr31509917lbj.7.1399457075103; Wed, 07 May 2014 03:04:35 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; i486-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:5076 Archived-At: 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. - Timo From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5081 Path: news.gmane.org!not-for-mail From: Stephen Thomas Newsgroups: gmane.linux.lib.musl.general Subject: RE: Linking musl with ld.gold Date: Thu, 8 May 2014 01:03:19 +0100 Message-ID: References: ,<20140506101410.GP12324@port70.net>,,<20140506231807.GQ12324@port70.net>,,<20140507130443.72c74f47@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_4f9b040d-f34b-4ce4-a809-065be517e017_" X-Trace: ger.gmane.org 1399507457 9719 80.91.229.3 (8 May 2014 00:04:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 00:04:17 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-5087-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 02:04:09 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 1WiBom-0001A1-FC for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 02:04:08 +0200 Original-Received: (qmail 7380 invoked by uid 550); 8 May 2014 00:04:06 -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 6113 invoked from network); 8 May 2014 00:03:31 -0000 X-TMN: [inVHgFu6ZzycXW26zcKYu62HPCe/zGgk] X-Originating-Email: [scjthm@live.com] Importance: Normal In-Reply-To: <20140507130443.72c74f47@vostro> X-OriginalArrivalTime: 08 May 2014 00:03:19.0075 (UTC) FILETIME=[EB116F30:01CF6A50] Xref: news.gmane.org gmane.linux.lib.musl.general:5081 Archived-At: --_4f9b040d-f34b-4ce4-a809-065be517e017_ Content-Type: multipart/alternative; boundary="_8800cd4f-43da-480e-970b-fa5e721509a5_" --_8800cd4f-43da-480e-970b-fa5e721509a5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > only the object files with referenced symbols are linked from an > > > archive > > >=20 > > > so only a.o with the given main.o because of the symbol f > > >=20 > > > 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 > > >=20 > > > eg. add a void g(void){} to b.c and call it from main.c =20 > >=20 > > Ok=2C thanks for that info. It appears that there is a problem in gcc > > 4.9 and not 4.8.3. >=20 > Is perhaps -ffunction-sections and/or -fdata-sections added > automatically? Those would break musl like experienced. Thanks for that tip=2C but I didn't change the sections in the linker scrip= t. I didn't add any flags either. I attach the single test case cleaned up = a bit. I ran this on the buildroot toolchain (standard config with uclibc a= nd with 2.24.0 binutils) with 4.8.2 and the result is 42. I rebuilt the too= lchain only changing the compiler version to 4.9.2 and the result is 0. This corroborates what I was seeing (or not as in the case of the prompt no= t appearing in busybox) with my builds also. Thomo = --_8800cd4f-43da-480e-970b-fa5e721509a5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B >= =3B only the object files with referenced symbols are linked from an
>= =3B >=3B >=3B archive
>=3B >=3B >=3B
>=3B >=3B >=3B = so only a.o with the given main.o because of the symbol f
>=3B >=3B = >=3B
>=3B >=3B >=3B now if you make some reference in main.c su= ch that b.o should
>=3B >=3B >=3B be included but main still retur= ns 0 that would be a bug
>=3B >=3B >=3B
>=3B >=3B >=3B e= g. add a void g(void){} to b.c and call it from main.c
>=3B >=3B <= br>>=3B >=3B Ok=2C thanks for that info. It appears that there is a pro= blem in gcc
>=3B >=3B 4.9 and not 4.8.3.
>=3B
>=3B Is per= haps -ffunction-sections and/or -fdata-sections added
>=3B automatical= ly? Those would break musl like experienced.

Thanks for t= hat tip=2C but I didn't change the sections in the linker script. I didn't = add any flags either. I attach the single test case cleaned up a bit. I ran= this on the buildroot toolchain (standard config with uclibc and with 2.24= .0 binutils) with 4.8.2 and the result is 42. I rebuilt the toolchain only = changing the compiler version to 4.9.2 and the result is 0.

<= /div>

This corroborates what I was seeing (or not as in the case of the= prompt not appearing in busybox) with my builds also.

Thomo

= --_8800cd4f-43da-480e-970b-fa5e721509a5_-- --_4f9b040d-f34b-4ce4-a809-065be517e017_ Content-Type: application/x-sh Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="badgcc.sh" IyEvYmluL3NoIC1lCkxPQURFUj0iIgpDQz0iZ2NjIgpBUj0iYXIiCk5NPSJubSIKRkxJU1Q9ImEu YyBiLmMgbWFpbi5jIGEubyBiLm8gbWFpbi5vIGEuYSBhIgpjZCAvdG1wCmlmIFsgIiQobHMgLWwg JHtGTElTVH0gMj4gL2Rldi9udWxsIHwgd2MgLWwpIiAhPSAiMCIgXSA7IHRoZW4KICAgIGVjaG8g IlNvcnJ5IG9uZSBvZiB0aGVzZSBmaWxlcyBleGlzdHMgJHtGTElTVH0gYW5kIEkgd291bGQgbGlr ZSB0byBvdmVyd3JpdGUgdGhlbSIKICAgIGV4aXQgMQpmaQpjYXQgPiBhLmMgPDwgX0VPRgovLyBh LmMKc3RydWN0IGZvbyB7aW50IGk7fTsKc3RhdGljIHN0cnVjdCBmb28gKmNvbnN0IGR1bW15ID0g MDsKZXh0ZXJuIHN0cnVjdCBmb28gKmNvbnN0IGhhc2ZvbyBfX2F0dHJpYnV0ZV9fKCh3ZWFrLCBh bGlhcygiZHVtbXkiKSkpOwppbnQgZih2b2lkKQp7CiAgICByZXR1cm4gaGFzZm9vID8gaGFzZm9v LT5pIDogMDsKfQpfRU9GCmNhdCA+IGIuYyA8PCBfRU9GCi8vIGIuYwpzdHJ1Y3QgZm9vIHtpbnQg aTt9OwpzdGF0aWMgc3RydWN0IGZvbyBmb28gPSB7LmkgPSA0Mn07CnN0cnVjdCBmb28gKmNvbnN0 IGhhc2ZvbyA9ICZmb287CnZvaWQgZygpCnsKfQpfRU9GCmNhdCA+IG1haW4uYyA8PCBfRU9GCi8v IG1haW4uYwppbnQgZih2b2lkKTsKdm9pZCBnKCk7CmludCBtYWluKCkKewogICAgZygpOwogICAg cmV0dXJuIGYoKTsKfQpfRU9GCiR7Q0N9ICR7Q0ZMQUdTfSAtYyBhLmMKJHtDQ30gJHtDRkxBR1N9 IC1jIGIuYwoke0NDfSAke0NGTEFHU30gLWMgbWFpbi5jCiR7Q0N9ICR7Q0ZMQUdTfSAtbyBhIG1h aW4ubyBhLm8gYi5vCmVjaG8gIioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiIKZWNobyAtbiAiUnVubmluZyB3aXRoIC4uLiIKJHtDQ30g LS12ZXJzaW9uCiR7QVJ9IHIgYS5hIGEubyBiLm8KJHtOTX0gYS5hCiR7Q0N9ICR7Q0ZMQUdTfSAt byBhIG1haW4ubyBhLmEKcmV0PTA7ICR7TE9BREVSfSAuL2EgfHwgcmV0PSR7P30KZWNobyAiRXhw ZWN0aW5nIDQyLCBnb3QgJHtyZXR9LiIKZWNobyAiKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIgpybSAtZiAke0ZMSVNUfQo= --_4f9b040d-f34b-4ce4-a809-065be517e017_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5082 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 21:06:05 -0400 Message-ID: <20140508010605.GE26358@brightrain.aerifal.cx> References: <20140506101410.GP12324@port70.net> <20140506231807.GQ12324@port70.net> <20140507130443.72c74f47@vostro> 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 1399511188 24193 80.91.229.3 (8 May 2014 01:06:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 01:06:28 +0000 (UTC) Cc: scjthm@live.com To: musl@lists.openwall.com Original-X-From: musl-return-5088-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 03:06:21 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 1WiCmw-0001GZ-Uh for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 03:06:19 +0200 Original-Received: (qmail 11859 invoked by uid 550); 8 May 2014 01:06:17 -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 11851 invoked from network); 8 May 2014 01:06:17 -0000 Content-Disposition: inline In-Reply-To: <20140507130443.72c74f47@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5082 Archived-At: 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. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5083 Path: news.gmane.org!not-for-mail From: Stephen Thomas Newsgroups: gmane.linux.lib.musl.general Subject: RE: Linking musl with ld.gold Date: Thu, 8 May 2014 03:08:41 +0100 Message-ID: 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: multipart/alternative; boundary="_190444db-d3eb-406c-bd41-855150baede5_" X-Trace: ger.gmane.org 1399514942 2593 80.91.229.3 (8 May 2014 02:09:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 02:09:02 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-5089-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 04:08:56 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 1WiDlX-00027h-3W for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 04:08:55 +0200 Original-Received: (qmail 20199 invoked by uid 550); 8 May 2014 02:08:54 -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 20191 invoked from network); 8 May 2014 02:08:53 -0000 X-TMN: [gxDcatWkUcT7KouOndXROY0qy303QWkC] X-Originating-Email: [scjthm@live.com] Importance: Normal In-Reply-To: <20140508010605.GE26358@brightrain.aerifal.cx> X-OriginalArrivalTime: 08 May 2014 02:08:41.0401 (UTC) FILETIME=[6EB94A90:01CF6A62] Xref: news.gmane.org gmane.linux.lib.musl.general:5083 Archived-At: --_190444db-d3eb-406c-bd41-855150baede5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > On Wed=2C May 07=2C 2014 at 01:04:43PM +0300=2C Timo Teras wrote: > > On Wed=2C 7 May 2014 10:04:24 +0100 > > Stephen Thomas wrote: > >=20 > > > > only the object files with referenced symbols are linked from an > > > > archive > > > >=20 > > > > so only a.o with the given main.o because of the symbol f > > > >=20 > > > > 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 > > > >=20 > > > > eg. add a void g(void){} to b.c and call it from main.c =20 > > >=20 > > > Ok=2C thanks for that info. It appears that there is a problem in gcc > > > 4.9 and not 4.8.3. > >=20 > > Is perhaps -ffunction-sections and/or -fdata-sections added > > automatically? Those would break musl like experienced. >=20 > They should not break musl=3B if they do=2C 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. >=20 > I suspect your claim is just wrong=2C 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 f= rom git=2C as it takes too long). I am not saying that the library doesn't = work=2C I am merely saying that there was a bug where stdout was not being = flushed=2C 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 buil= ds and the result was different. This was on two clean buildroot branches b= ased on uclibc.=20 I don't understand what you mean by garbage collection. Basically=2C if I u= nderstand this correctly=2C 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 (wh= ich is just basically a manufactured wrapper around file descriptor number = 1). This is good as far as unit testing goes=2C doesn't use #defines but th= e linker -- good stuff. However=2C when I noticed was that the prompt on = busybox using musl was not appearing until after a new line was entered=2C = I added a discovered that the value of the pointer was 0 (NULL). If you sti= ll suspect that my claim is wrong=2C then I believe you are saying that thi= s is not the case. It would be nice if someone who has gcc 4.9 installed co= uld run either run the test or check that busybox is working.=20 Thomo = --_190444db-d3eb-406c-bd41-855150baede5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B On Wed=2C Ma= y 07=2C 2014 at 01:04:43PM +0300=2C Timo Teras wrote:
>=3B >=3B On W= ed=2C 7 May 2014 10:04:24 +0100
>=3B >=3B Stephen Thomas <=3Bscjth= m@live.com>=3B wrote:
>=3B >=3B
>=3B >=3B >=3B >=3B on= ly the object files with referenced symbols are linked from an
>=3B &g= t=3B >=3B >=3B archive
>=3B >=3B >=3B >=3B
>=3B >=3B= >=3B >=3B so only a.o with the given main.o because of the symbol f>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B now if you mak= e some reference in main.c such that b.o should
>=3B >=3B >=3B >= =3B be included but main still returns 0 that would be a bug
>=3B >= =3B >=3B >=3B
>=3B >=3B >=3B >=3B eg. add a void g(void){} = to b.c and call it from main.c
>=3B >=3B >=3B
>=3B >=3B = >=3B Ok=2C thanks for that info. It appears that there is a problem in gc= c
>=3B >=3B >=3B 4.9 and not 4.8.3.
>=3B >=3B
>=3B &g= t=3B Is perhaps -ffunction-sections and/or -fdata-sections added
>=3B = >=3B automatically? Those would break musl like experienced.
>=3B >=3B They should not break musl=3B if they do=2C it's a compiler bug. T= he
>=3B strong symbol that overrides the weak symbol elsewhere is not = unused
>=3B and available for garbage collection because it's referenc= ed.
>=3B
>=3B I suspect your claim is just wrong=2C since IIRC p= eople have
>=3B 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=2C as it takes too long). I am not saying that the library d= oesn't work=2C I am merely saying that there was a bug where stdout was not= being flushed=2C and this in my opinion was due to the weak symbol in fflu= sh not being overridden. I did run that single test case on the two differe= nt builds and the result was different. This was on two clean buildroot bra= nches based on uclibc. =3B

I don't understand = what you mean by garbage collection. Basically=2C if I understand this corr= ectly=2C there is a weak symbol defined in fflush.c for the purpose of allo= wing this file to run without the an implementation that initialises the re= al symbol with the internal implementation of stdout (which is just basical= ly a manufactured wrapper around file descriptor number 1). This is good as= far as unit testing goes=2C doesn't use #defines but the linker -- good st= uff. However=2C =3Bwhen =3BI noticed was that the prompt on busyb= ox using musl was not appearing until after a new line was entered=2C I add= ed a discovered that the value of the pointer was 0 (NULL). If you still su= spect that my claim is wrong=2C then I believe you are saying that this is = not the case. It would be nice if someon= e who has gcc 4.9 installed could run either run the test or check that bus= ybox is working. =3B

Thomo

= --_190444db-d3eb-406c-bd41-855150baede5_-- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5086 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Linking musl with ld.gold Date: Thu, 8 May 2014 08:11:26 +0300 Message-ID: <20140508081126.140b0064@vostro> 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 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399525897 29353 80.91.229.3 (8 May 2014 05:11:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 05:11:37 +0000 (UTC) Cc: dalias@libc.org, scjthm@live.com To: musl@lists.openwall.com Original-X-From: musl-return-5092-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 07:11:30 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 1WiGcC-0000a3-TQ for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 07:11:28 +0200 Original-Received: (qmail 28126 invoked by uid 550); 8 May 2014 05:11:28 -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 28117 invoked from network); 8 May 2014 05:11:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=WwOgDwJiscP9SVZTLyiL1bsrxN3v25vFSVPT90cx4KI=; b=PaZTzsGDZI0gzkp0m3JopJk0NzDk91BovWZEH/BorXoyMqYhEYrjDjwSz5WDYg+7TF BDviVWqmrB+zNU9/7AQEDPthuKH4+taLs2uM+sCIqSC0O9Gz4uW8ykXYfTWHCTzdorfZ Hu6o0q2+QzNJIw8Dpyufw0eEd2yXxu71I4HJ8QlgNRQqS1y9U+8RlKUfySm/H21KQj5V 0rgThuWvRG38UGo0h2SGWZUcpnZQ8lw5AKPUuLliMH+F3lrSDEof3O3PMWO6GQ5Taa0G yKMSs5DbZ8OIAcxoIFk7g2lReiKn6BvbWY7JuNMYozkR6Jes2/qKNC2s6LDwLRRbh7w5 B8wg== X-Received: by 10.112.106.40 with SMTP id gr8mr2012302lbb.0.1399525876684; Wed, 07 May 2014 22:11:16 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20140508010605.GE26358@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; i486-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:5086 Archived-At: On Wed, 7 May 2014 21:06:05 -0400 Rich Felker wrote: > On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote: > > 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. -fdata-sections breaks things to my understanding. stdin.c (and others), have: FILE *const stdin = &f; FILE *const __stdin_used = &f; And __stdin_used is only ever referenced via weak alias. -fdata-section makes each symbol go to different section, and if linker has gc-sections, it'll remove any unreferenced section. This means __stdin_used will never get pulled in causing problems like described in the original mail. With -ffunction-sections/-fdata-sections/-Wl,--gc-sections it is no longer valid assumption that if compilation unit gets pulled in, all of the symbols defined in it will get pulled in. Of course this does not affect .so as visible exported symbols are reachable and not GCd. But static build would be effected. - Timo From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5087 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Linking musl with ld.gold Date: Thu, 8 May 2014 01:18:21 -0400 Message-ID: <20140508051821.GG26358@brightrain.aerifal.cx> References: <20140506101410.GP12324@port70.net> <20140506231807.GQ12324@port70.net> <20140507130443.72c74f47@vostro> <20140508010605.GE26358@brightrain.aerifal.cx> <20140508081126.140b0064@vostro> 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 1399526334 2061 80.91.229.3 (8 May 2014 05:18:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 05:18:54 +0000 (UTC) Cc: musl@lists.openwall.com, scjthm@live.com To: Timo Teras Original-X-From: musl-return-5093-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 07:18:46 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 1WiGjD-0005ag-UZ for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 07:18:44 +0200 Original-Received: (qmail 32640 invoked by uid 550); 8 May 2014 05:18:43 -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 32629 invoked from network); 8 May 2014 05:18:43 -0000 Content-Disposition: inline In-Reply-To: <20140508081126.140b0064@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5087 Archived-At: On Thu, May 08, 2014 at 08:11:26AM +0300, Timo Teras wrote: > On Wed, 7 May 2014 21:06:05 -0400 > Rich Felker wrote: > > > On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote: > > > 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. > > -fdata-sections breaks things to my understanding. > > stdin.c (and others), have: > > FILE *const stdin = &f; > FILE *const __stdin_used = &f; > > And __stdin_used is only ever referenced via weak alias. -fdata-section > makes each symbol go to different section, and if linker has > gc-sections, it'll remove any unreferenced section. This means But the section is not unreferenced. There's a reference to __stdin_used from __stdio_exit.o. Ignoring this reference just because it could have been satisfied by a weak symbol is wrong. > __stdin_used will never get pulled in causing problems like described > in the original mail. I don't see anywhere it's documented to behave this way, and in fact making it behave this way would not only be harmful but more difficult than making it behave correctly. The basic way a linker works is to pull in all objects to satisfy undefined symbols; performing GC on sections is a separate task that takes place (or at least should) after all symbols have been resolved, and thus once it's possible to know which symbols are referenced and which are not. Rich