Re: DT_TEXTREL/.dynamic issue with the binutils 2.15 linker on ARM and Linux

[Daniel Jacobowitz <drow at false dot org>]

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