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