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
Copyright (C) 201= 3 Free Software Foundation=2C Inc.
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
Copyright (C= ) 2014 Free Software Foundation=2C Inc.
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_--