Bug 19531

Summary:	ld fails to build proper executables in several cases on x64_64-w64-mingw32
Product:	binutils	Reporter:	Rainer Emrich <rainer>
Component:	ld	Assignee:	Not yet assigned to anyone <unassigned>
Status:	ASSIGNED ---
Severity:	normal	CC:	ismail, kyrab, nickc, steve
Priority:	P2
Version:	2.26
Target Milestone:	---
Host:	x86_64-w64-mingw32	Target:	x86_64-w64-mingw32
Build:	x86_64-w64-mingw32	Last reconfirmed:
Attachments:	test case Keep .rdata_runtime_pseudo_reloc from being gc collected section headers produced by ld-2.25.1 section headers produced by ld-2.26 private headers produced by ld-2.25.1 private headers produced by ld-2.26 symbol tables produced by ld-2.25.1 symbol tables produced by ld-2.26

Description Rainer Emrich 2016-01-29 10:17:32 UTC

Created attachment 8929 [details]
test case

I first discovered this by bootstrapping gcc and running the testsuite. I got around 1200 new failures for the same gcc revision using binutils-2.26 compared to using binutils-2.25.1, see
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02756.html
and
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02757.html

Most failures in the libstdc++ testsuite, 954 additional failures.

Besides the new failures, some tests which PASS and a some which FAIL allocate huge memory spaces, over 40 GByte.

So I tried to analyze a bit. I picked a test case from the libstdc++ testsuite 22_locale/locale/cons/6.cc. Checking the preprocessed source, the assemply and the object files for the support library and the test case itself there's no difference. I disabled all debug information for an easier comparison. The objects are identical for both versions.

I attach a test archive containing the support library and the object file, two versions of the executable and the two dlls libstdc++-6.dll and libgcc_s_seh-1.dll
to run the executables on a windows system.
The executable 6-2.15.1.exe is the one which is linked using ld-2.15.1, the executable 6-2.16.exe is the one which is linked using ld-2.16.
The first one is fine the latter isn't.

I don't know how to analyze any further. Can someone have a look, please.

Comment 1 Rainer Emrich 2016-01-29 10:25:41 UTC

Ah, forgot the linking command:
g++ -shared-libgcc -fmessage-length=0 -ffunction-sections -fdata-sections -g0 -O2 -fno-diagnostics-show-caret -fdiagnostics-color=never ./6.o ./libtestc++.a -Wl,--gc-sections -liconv -lm -o 6.exe

Comment 2 awson 2016-02-27 11:01:58 UTC

Created attachment 9045 [details]
Keep .rdata_runtime_pseudo_reloc from being gc collected

Comment 3 awson 2016-02-27 11:02:59 UTC

Did you try to inspect the executable linked with 2.16 to understand how many sections it contains? Perhaps, existing linker script doesn't merge some kind(s) of sections correctly?

Also, current ld script is buggy and causes segfaults in some C++ programs on Windows with --gc-sections. I've attached the patch, perhaps it will cure some of your problems.

Comment 4 Rainer Emrich 2016-03-16 08:19:37 UTC

Created attachment 9098 [details]
section headers produced by ld-2.25.1

Im adding the objdump output for section headers, private headers and symbol tables produced by binutils-2.15.1 and binutils-2.16.

I can't really interpret this data, but it's obvious that the .rdata section produced by ld-2.15.1 is much larger than the version produced by ld-2.16.

The symbol tables are really different.

Comment 5 Rainer Emrich 2016-03-16 08:20:29 UTC

Created attachment 9099 [details]
section headers produced by ld-2.26

Comment 6 Rainer Emrich 2016-03-16 08:22:07 UTC

Created attachment 9100 [details]
private headers produced by ld-2.25.1

Comment 7 Rainer Emrich 2016-03-16 08:22:39 UTC

Created attachment 9101 [details]
private headers produced by ld-2.26

Comment 8 Rainer Emrich 2016-03-16 08:23:38 UTC

Created attachment 9102 [details]
symbol tables produced by ld-2.25.1

Comment 9 Rainer Emrich 2016-03-16 08:24:09 UTC

Created attachment 9103 [details]
symbol tables produced by ld-2.26

Comment 10 Rainer Emrich 2016-03-17 16:01:32 UTC

(In reply to awson from comment #2)
> Created attachment 9045 [details]
> Keep .rdata_runtime_pseudo_reloc from being gc collected

Ok, that improves the situation a lot. I get a lot less failures than with an unpatchted binutils-2.26 version, but still a lot more than with a binutils-2.25.1.

To add some numbers for the libstdc++ testsuite:

binutils-version  PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1            9911      0    51     67          27          890
2.26              8890      1  1006     66          27          896
2.26-patched      9343      0   500     67          27          890

So, I think this patch should go in. But some one has to analyze the issues further. I may try this, but this will be in may earliest.

Sorry for give the wrong version sometimes. It's the version 2.26 which has the issues and I compare to version 2.25.1. I hope that's clear.

Comment 11 Sourceware Commits 2016-03-18 11:47:17 UTC

The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=45821bef0977a7436aa5cd5f37f5a178d446d675

commit 45821bef0977a7436aa5cd5f37f5a178d446d675
Author: Awson <kyrab@mail.ru>
Date:   Fri Mar 18 11:45:43 2016 +0000

    Ensure that the .rdata_pseudo_runtime_reloc sections are not discarded by gabage collection.
    
    	PR 19531
    	* scripttempl/pe.sc (.rdata_runtime_pseudo_reloc): Always KEEP
    	this section.
    	* scripttempl/pep.sc (.rdata_runtime_pseudo_reloc): Likewise.

Comment 12 Nick Clifton 2016-03-18 11:49:29 UTC

Hi Rainer,

> So, I think this patch should go in.

Done.

>  But some one has to analyze the issues further. 

Would you mind trying out patch VII in PR 19803 and see if that makes a difference ?

https://sourceware.org/bugzilla/show_bug.cgi?id=19803

Cheers
  Nick

Comment 13 Rainer Emrich 2016-03-18 16:07:26 UTC

Hi Nick,

Am 18.03.2016 um 12:49 schrieb nickc at redhat dot com:
> Would you mind trying out patch VII in PR 19803 and see if that makes a
> difference ?
sure! But that's a little bit difficult now, at least for binutils-2.26,
because the patch doesn't apply.
Third hunk for ldlang.c and first hunk for pe-dll.c fail.
I took a quick look into the files but for me it's not obvious how to
apply this changes.

Cheers

Rainer

Comment 14 Rainer Emrich 2016-03-18 16:16:55 UTC

Hi Nick,

Am 18.03.2016 um 17:07 schrieb Rainer Emrich:
> Am 18.03.2016 um 12:49 schrieb nickc at redhat dot com:
>> Would you mind trying out patch VII in PR 19803 and see if that makes a
>> difference ?
> sure! But that's a little bit difficult now, at least for binutils-2.26,
> because the patch doesn't apply.
> Third hunk for ldlang.c and first hunk for pe-dll.c fail.
> I took a quick look into the files but for me it's not obvious how to
> apply this changes.
I'm testing master instead!

Cheers

Rainer

Comment 15 Rainer Emrich 2016-03-19 18:10:15 UTC

(In reply to Nick Clifton from comment #12)
> Hi Rainer,
> Would you mind trying out patch VII in PR 19803 and see if that makes a
> difference ?
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19803
> 
> Cheers
>   Nick

The patch cures nearly all of the failures introduces by binutils-2.26 compared to binutils-2.25.1, so I think this patch should go in! Do you think it's possible to backport this patch to the 2.26 branch?

FYI I add some numbers showing the differences in the several gcc testsuites for master this patch included compared to binutils-2.25. There are still some differences specially in the libgomp testsuite. There are a few new failures.

Complete test results for gcc are at https://gcc.gnu.org/ml/gcc-testresults/2016-03/msg02006.html

testsuite gcc:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1            106895     12   727    328          17         1834
2.26-patched      106841     12   725    328          17         1834

testsuite g++:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1             93961      3   521    278          12         3785
2.26-patched       93961      3   521    278          12         3785

testsuite gfortran:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1             41578      0   278     75           0          167
2.26-patched       41556      0   278     75           0          167

testsuite ada:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1              2315      0     5      0           0            0
2.26-patched        2315      0     5      0           0            0

testsuite gnat:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1              2491      0     8     22           0            4
2.26-patched        2491      0     8     22           0            4

testsuite objc:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1              2735      0    14      6           0           68
2.26-patched        2735      0    14      6           0           68

testsuite libatomic:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1                54      0     0      2           0            0
2.26-patched          54      0     0      2           0            0

testsuite libgomp:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1              4859      0    26      0           6          262
2.26-patched        4804      0    51      0          36          262

testsuite libstdc++-v3:
binutils-version    PASS  XPASS  FAIL  XFAIL  UNRESOLVED  UNSUPPORTED
2.25.1              9911      0    51     67          27          890
2.26-patched        9911      0    51     67          27          890

I don't know why the sum of all tests isn't always equal between the both runs. In the gcc and fortran testsuite the sums are unequal.

Comment 16 Nick Clifton 2016-03-22 12:34:07 UTC

Hi Rainer,

> The patch cures nearly all of the failures introduces by binutils-2.26
> compared to binutils-2.25.1, so I think this patch should go in!

Done.

>  Do you
> think it's possible to backport this patch to the 2.26 branch?

Possible yes, but I do not think that it is the right time.  I would rather check in a complete patch that fixes all of the problems, not just a partial patch that still leaves some things broken.

I have just updated PR 19803 with another small, additional patch.  Please could you give this one a try out as well and let me know if it makes any difference ?

Cheers
  Nick

Comment 17 Rainer Emrich 2016-03-23 10:50:24 UTC

Am 22.03.2016 um 13:34 schrieb nickc at redhat dot com:
> I have just updated PR 19803 with another small, additional patch.  Please
> could you give this one a try out as well and let me know if it makes any
> difference ?
Sure, already running.

Cheers

Rainer

Comment 18 Rainer Emrich 2016-03-23 15:48:22 UTC

Am 23.03.2016 um 11:49 schrieb Rainer Emrich:
> Am 22.03.2016 um 13:34 schrieb nickc at redhat dot com:
>> I have just updated PR 19803 with another small, additional patch.  Please
>> could you give this one a try out as well and let me know if it makes any
>> difference ?
> Sure, already running.
No, there is no difference for x86_64-w64-mingw32 AFAIS.

Cheers

Rainer

Comment 19 Nick Clifton 2016-03-24 09:35:25 UTC

(In reply to Rainer Emrich from comment #18)
 
> No, there is no difference for x86_64-w64-mingw32 AFAIS.
 
Oh bananas!

Any idea what is special about libgomp ?  I am not familiar with it myself, and I am wondering if the failures are due to something completely unrelated to linker garbage collection.  (Do the failures go away if tested with -Wl,-no-gc-sections ?)

Cheers
  Nick

Comment 20 Rainer Emrich 2016-03-26 08:30:20 UTC

Am 24.03.2016 um 10:35 schrieb nickc at redhat dot com:
> Any idea what is special about libgomp ?  I am not familiar with it myself, and
> I am wondering if the failures are due to something completely unrelated to
> linker garbage collection.  (Do the failures go away if tested with
> -Wl,-no-gc-sections ?)

I investigate further, but this will be after the 4th of April. I'm on
vacation and away from my test system.

Cheers

Rainer