Discrepancy with .reloc section between PE and PE+ emulations when linking -r.

Dave Korn dave.korn.cygwin@googlemail.com
Fri Feb 13 20:50:00 GMT 2009


Dave Korn wrote:

> Now testing this proposed fix on a whole slew of linux-x-PE cross-targets.

  Testing finished.  No regressions, and fixed a bunch of failures on
sh-unknown-pe:

[root@ubique binutils]# grep -A8 'ld Summary' obj-sh-unpatched/check.log
		=== ld Summary ===

# of expected passes		2
# of unexpected failures	36
# of expected failures		3
# of unresolved testcases	1
# of untested testcases		16
# of unsupported tests		2
/gnu/binutils/obj-sh-unpatched/ld/ld-new 2.19.51.20090213

[root@ubique binutils]# grep -A9 'ld Summary' obj-sh-patched/check.log
		=== ld Summary ===

# of expected passes		18
# of unexpected failures	20
# of unexpected successes	1
# of expected failures		2
# of unresolved testcases	1
# of untested testcases		16
# of unsupported tests		2
/gnu/binutils/obj-sh-patched/ld/ld-new 2.19.51.20090213


  There was a SEGV in pe-dll.c/generate_reloc(), caused by the global reloc_s
pointer not having been initialised to point to a blank BFD; apparently SH
does use .reloc sections in fully-linked executable images, so it was really
suffering from missing that call to pe_exe_build_sections() that was
needlessly being taken by the x86 and ARM targets instead.  There's still a
load of failures, so I don't know if it's necessarily resolved all the
problems, I'll look a little deeper while I'm respinning the long section
names patch.

  It also fixes the ld-bootstrap "bootstrap" test on Cygwin.

ld/ChangeLog

	* emultempl/pe.em (gld_${EMULATION_NAME}_after_open):  Don't emit
	inadvertent .reloc sections caused by refactoring accident.

  Ok?

    cheers,
      DaveK


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pei-reloc-section-patch.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20090213/68683c79/attachment.ksh>


More information about the Binutils mailing list