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_--