[Bug ld/19030] New: ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[address@hidden]

https://sourceware.org/bugzilla/show_bug.cgi?id=19030

            Bug ID: 19030
           Summary: ld generates .so/x86 with bad phdr so the Android
                    linker won't dlopen
           Product: binutils
           Version: 2.25
               URL: https://code.google.com/p/android/issues/detail?id=187
                    850
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: address@hidden
  Target Milestone: ---
              Host: x86
            Target: x86

Created attachment 8651
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8651&action=edit
.so with supposedly broken structure

I originally reported the Bug to Android since a generated .so file could not
by loaded by their linker/loader but they claim ld is a fault for generating a
flawed ELF structure.

To quote:
"The so file in question is a strange one. Android linker assumes that phdr
table is part of loadable segment but looking at the bad.so the load segment
has the offset > sizeof(ehdr) + sizeof(phdr), so it ends up not being mapped
into the memory - hence inaccessible after the library is loaded.

I think the ld is broken (or very old). What does ld --version say?

There are some other irregularities like one load segment for data and
executable with RWE permission. And p_vaddr which might assume fixed
load-address despite the fact that the object type is set to ET_DYN."

For my minimal test case I linked an object file (generated from a C file with
an empty function) like this:
$ ld -L /usr/lib/android-ndk/x86/usr/lib -o client-ndk-x86.so -shared -nostdlib
-lc obj-client-ndk-x86/test.o

As mentioned in the original bug report, ld.gold generates an ELF structure
which works for the Android loader.

-- 
You are receiving this mail because:
You are on the CC list for the bug.