https://sourceware.org/bugzilla/show_bug.cgi?id=19623
Bug ID: 19623
Summary: regression: missing relocation for symbols in
discarded section
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: winter-...@bfw-online.de
Target Milestone: ---
Created attachment 8981
--> https://sourceware.org/bugzilla/attachment.cgi?id=8981&action=edit
Patch that reverts 3a062fa1eeee8296dece36a9bb7ecc8d4500de18
Hi,
my target is i586-pc-sco3.2v4.2 and I recently upgraded binutils in Debian from
version 2.25 to 2.26. After that my SCO binaries would crash when I executed
them. I discovered that the reallocation of symbol addresses did not work
anymore. I bisected the issue the following commit:
3a062fa1eeee8296dece36a9bb7ecc8d4500de18
For my setup I am just reverting it (which is ironic since the commit itself is
a revert). From my limited understanding of the code at hand it seems to me
that
a) "sec->output_section->vma == 0" might be convered in the discarded_section
macro
b) the call to _bfd_clear_contents seems to be undesirable in my SCO scenario
Unfortunately I cannot provide you with the object files I am linking because
they are proprietary but If you are really need a test case, I might be able to
to program a minimal test case which reflects my problem. However I have not
created such a test case yet.
My linking setup looks like this:
I have a lot of object files, including an object with asm like this:
00006af4 <foo_patch>:
6af4: 8b 4d 08 mov 0x8(%ebp),%ecx
6af7: 8b 09 mov (%ecx),%ecx
6af9: 03 01 add (%ecx),%eax
6afb: 83 f8 ff cmp $0xffffffff,%eax
6afe: 0f 84 39 e3 ff ff je 4e3d <foo+0x15a>
6b04: e9 c5 e2 ff ff jmp 4dce <foo+0xeb>
6b09: 90 nop
6b0a: 90 nop
6b0b: 90 nop
00006b0c <bar_patch>:
6b0c: 8b 45 fc mov -0x4(%ebp),%eax
6b0f: 83 f8 00 cmp $0x0,%eax
6b12: 0f 8c 05 b9 ff ff jl 241d <bar+0x403>
6b18: 8b 45 f0 mov -0x10(%ebp),%eax
6b1b: 2b 45 fc sub -0x4(%ebp),%eax
6b1e: e9 e8 b8 ff ff jmp 240b <bar+0x3f1>
After the linking the result looks like this:
00010e74 <foo_patch>:
10e74: 8b 4d 08 mov 0x8(%ebp),%ecx
10e77: 8b 09 mov (%ecx),%ecx
10e79: 03 01 add (%ecx),%eax
10e7b: 83 f8 ff cmp $0xffffffff,%eax
10e7e: 0f 84 39 e3 ff ff je f1bd <foo+0x15a>
10e84: e9 c5 e2 ff ff jmp f14e <foo+0xeb>
10e89: 90 nop
10e8a: 90 nop
10e8b: 90 nop
00010e8c <bar_patch>:
10e8c: 8b 45 fc mov -0x4(%ebp),%eax
10e8f: 83 f8 00 cmp $0x0,%eax
10e92: 0f 8c 85 15 ff ff jl 241d <fail+0x45b>
10e98: 8b 45 f0 mov -0x10(%ebp),%eax
10e9b: 2b 45 fc sub -0x4(%ebp),%eax
10e9e: e9 68 15 ff ff jmp 240b <fail+0x449>
Note that all the jump addresses stayed the same. Fortunately for "foo_patch",
the relative offset is still accurate. However "bar_patch" now points to "fail"
instead of "bar", probably because the function changed its position because of
other objects linked in.
I attach my trivial revert of the commit (which makes my setup work again).
Regards,
Leon
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
