search

send2vinnie / mclinker

Automatically exported from code.google.com/p/mclinker
Other
0 stars 0 forks source link

Different behaviors of gnu-ld and gold when handling relocation R_ARM_ABS32 #13

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
When generating .so, gnu-ld and gold has different results:
----------------------------------------------------------------
$ gnu-ld ABS32.o -shared -o abs_ld.so
$ readelf -r abs_ld.so
Relocation section '.rel.dyn' at offset 0x200 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000220  00000017 R_ARM_RELATIVE
00000224  00000017 R_ARM_RELATIVE
00000228  00000902 R_ARM_ABS32       00000220   foo
0000022c  00000802 R_ARM_ABS32       000082b4   globalv

----------------------------------------------------------------
$ gold-ld ABS32.o -shared -o abs_gold.so
$ readelf -r abs_gold.so
Relocation section '.rel.dyn' at offset 0x168 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
000001b0  00000017 R_ARM_RELATIVE
000001b4  00000017 R_ARM_RELATIVE
000001b8  00000102 R_ARM_ABS32       000001b0   foo
000001bc  00000202 R_ARM_ABS32       00001268   globalv

Relocation section '.rel.plt' at offset 0x188 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00001284  00000116 R_ARM_JUMP_SLOT   000001b0   foo
----------------------------------------------------------------

gold will generate a PLT entry for symbol 'foo', but gnu-ld won't. gold won't 
generate such PLT if the option '-Bsymbolic' is given. MCLinker follows gold's 
rule when handling ARM relocation, so we got this difference when testing the 
compatibility with gnu-ld.

Original issue reported on code.google.com by mysekki on 18 Jan 2012 at 9:03

Attachments:

GoogleCodeExporter commented 9 years ago 
We also can find this behavior in X86 backend (and others probably). And there 
is a related segfault when linking a fbsd kernel module:
ld.mcld -march=x86 -shared -o cam.ko.debug cam.kld

Currently the target fragref in output relocs may not be set, because the 
condition checks for symbolNeedsDynRel() might return different values in 
scan/apply functions. We probably should set up output relocs in scan functions 
instead. Doing so can also remove the same checks in apply functions. And then 
we can consider to follow bfd to save the cost of plt entry.

Original comment by pete.c...@gmail.com on 11 Sep 2013 at 3:12

Attachments: