[forwarded from http://bugs.debian.org/255191]

rechecked with 2.19 and trunk.

The gc libs in the bigloo package, built as non-PIC for performance reason
on platforms that support mixing PIC and non-PIC, contain an R_ARM_PC24
relocation:

0000b328  0001a001 R_ARM_PC24        0000c134   GC_push_current_stack

However, the lib is not flagged as containing relocations in the text
segment:

  Flags:                             0x2, has entry point, GNU EABI


This appears to be the cause of ld-linux.so segfaulting when it processes
this relocation:

$ LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes
/usr/lib/debug/ld-linux.so.2 ./bin/bdb
        libbigloobdl_s-2.6d.so =>
/home/ydirson/bigloo-2.6d-32-O1-g/lib/2.6d/libbigloobdl_s-2.6d.so (0x40001000)
        libbigloo_s-2.6d.so =>
/home/ydirson/bigloo-2.6d-32-O1-g/lib/2.6d/libbigloo_s-2.6d.so (0x40038000)
        libbigloogc-2.6d.so =>
/home/ydirson/bigloo-2.6d-32-O1-g/lib/2.6d/libbigloogc-2.6d.so (0x401b2000)
        libdl.so.2 => /lib/libdl.so.2 (0x401e2000)
        libm.so.6 => /lib/libm.so.6 (0x401ec000)
        libc.so.6 => /lib/libc.so.6 (0x40266000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4038c000)
        /lib/ld-linux.so.2 => /usr/lib/debug/ld-linux.so.2 (0x2aaaa000)
Segmentation fault (core dumped)

As a workaround, I'll force building PIC code on ARM.


Detailed analysis (from Philip Blundell):

$ gdb /usr/lib/debug/ld-linux.so.2 core
[...]
Core was generated by /usr/lib/debug/ld-linux.so.2 ./bin/bdb'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x2aab36bc


0x2aab36bc - 0x2aaaa000 = 96bc

and:

    96b4:       e3c034ff        bic     r3, r0, #-16777216      ; 0xff000000
    96b8:       e1824003        orr     r4, r2, r3
    96bc:       e58c4000        str     r4, [ip]
    96c0:       eaffffe6        b       9660 <_dl_relocate_object+0xcac>
		
Phil has identified this to be the code that relocates R_ARM_PC24 relocs.

Here's a small testcase.

$ echo "f() { return g(); }" > t.c
$ gcc -shared -o t.so t.c
$ readelf -d t.so | grep TEXTREL

If the linker is behaving correctly, the last command should output a
line like:

 0x00000016 (TEXTREL)                    0x0

p.