DT_TEXTREL/.dynamic issue with the binutils 2.15 linker on ARM and Linux
Daniel Jacobowitz
drow@false.org
Fri May 28 15:33:00 GMT 2004
On Fri, May 28, 2004 at 08:52:58AM -0600, David Poole wrote:
> (I'm far from an expert, ARM, ELF, or otherwise, so if I'm using some
> wrong terms, bear with me.)
>
> I'm working with ARM Linux and uClibc. The uClibc shared library loader
> segfaults. I've tracked the problem down to the loader attempting to
> modify a R_ARM_PC24 call in uClibc/ldso/ldso/arm/resolve.S. The
> location needing the modification is in a .rel.text section and the
> page is read-only. The loader attempts to modify a branch instruction
> to include the correct offset and the CPU rightly faults.
>
> The linker code needing relocation is:
>
> _dl_linux_resolve:
> stmdb sp!, {r0, r1, r2, r3, sl, fp}
> sub r1, ip, lr
> sub r1, r1, #4
> add r1, r1, r1
> ldr r0, [lr, #-4]
> mov r3,r0
>
> bl _dl_linux_resolver
>
> mov ip, r0
> ldmia sp!, {r0, r1, r2, r3, sl, fp, lr}
> mov pc,ip
> .size _dl_linux_resolve, .-_dl_linux_resolve
>
> The "bl _dl_linux_resolver" is causing the problem.
> The current problem I'm trying to solve is to understand why the
> DT_TEXTREL isn't appearing in the executable and whether it should be
> there. I'm poking around in bfd/elf32-arm.h -
> elf32_arm_size_dynamic_sections().
I don't know why DT_TEXTREL isn't there for this case. It should be.
But this case shouldn't be happening at all - is the linker built with
-shared? If so binutils 2.15 has all the magic to create a PLT entry
automatically.
Please create a complete linkable testcase that shows this.
If you write bl _dl_linux_resolver(PLT), normally you'd get a PLT
entry. But in binutils 2.15 I made that unnecessary.
--
Daniel Jacobowitz
More information about the Binutils
mailing list