Re: ELIBBAD when linked with gold

[Erwan Legrand <lists at erwanlegrand dot com>]

Hi Cary,

Thanks!

I should have mentionned I had noticed this discrepancy:

$ ldd good | grep ld-linux
    /lib64/ld-linux-x86-64.so.2 (0x00000038c1a00000)
$ ldd bad | grep ld-linux
    /lib/ld-linux.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00000038c1a00000)

Probably this would have saved a round-trip as readelf -l tells us
just the same:

[erwan@erwan-desktop cmgw-5.0]$ readelf -l cmgw | grep INTERP -A2
  INTERP         0x0000000000000270 0x0000000000000270 0x0000000000000270
                 0x0000000000000033 0x0000000000000033  R      10
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[erwan@erwan-desktop cmgw-5.0]$ readelf -l cmgw.bad | grep INTERP -A2
  INTERP         0x0000000000936310 0x0000000000936310 0x0000000000936310
                 0x0000000000000013 0x0000000000000013  R      10
      [Requesting program interpreter: /lib/ld-linux.so.2]

I had not noticed this read /lib/ instead of /lib64/, though:
$ ls -l /lib/ld-linux.so.2
lrwxrwxrwx. 1 root root 10 Feb  4 10:39 /lib/ld-linux.so.2 -> ld-2.18.so

Now, I wonder why ldd reports /lib/ld-linux.so.2 as being resolved as
/lib64/ld-linux-x86-64.so.2. This is what led me to think the
discrepancy was OK in the first place. To me , this looks like a bug
in ldd.

Digging a little further, it appears gold ignores the "-dynamic-linker
/lib64/ld-linux-x86-64.so.2" command line parameter in this case, as
create_interp() is not called, as shown in this gdb session:

(gdb) l
2677                      &versions);
2678
2679          // Create the .interp section to hold the name of the
2680          // interpreter, and put it in a PT_INTERP segment.  Don't do it
2681          // if we saw a .interp section in an input file.
2682          if ((!parameters->options().shared()
2683           || parameters->options().dynamic_linker() != NULL)
2684          && this->interp_segment_ == NULL)
2685        this->create_interp(target);
2686
(gdb) p this->interp_segment_
$2 = (gold::Output_segment *) 0x4cd3b40

This is because interp_segment_ was created here:

(gdb) bt
#0  gold::Layout::make_output_segment (this=0x7fffffff4de0, type=3,
flags=4) at layout.cc:5207
#1  0x0000000000542a43 in
gold::Layout::attach_allocated_section_to_segment
(this=this@entry=0x7fffffff4de0, target=target@entry=0xa79bd0,
os=0x46d9720) at layout.cc:2013
#2  0x0000000000542ae4 in gold::Layout::attach_section_to_segment
(this=this@entry=0x7fffffff4de0, target=target@entry=0xa79bd0,
os=0x46d9720) at layout.cc:1856
#3  0x0000000000543df2 in gold::Layout::attach_sections_to_segments
(this=this@entry=0x7fffffff4de0, target=target@entry=0xa79bd0) at
layout.cc:1843
#4  0x00000000005171fa in gold::queue_middle_tasks (options=...,
task=<optimized out>, input_objects=0x7fffffff4950,
symtab=0x7fffffff4b80, layout=0x7fffffff4de0,
workqueue=0x7fffffff4830, mapfile=0x0)
    at gold.cc:680
#5  0x000000000051782a in gold::Middle_runner::run (this=<optimized
out>, workqueue=<optimized out>, task=<optimized out>) at gold.cc:135
#6  0x000000000061aad5 in gold::Workqueue::find_and_run_task
(this=this@entry=0x7fffffff4830, thread_number=thread_number@entry=0)
at workqueue.cc:319
#7  0x000000000061adfa in gold::Workqueue::process
(this=this@entry=0x7fffffff4830, thread_number=thread_number@entry=0)
at workqueue.cc:495
#8  0x000000000041b83c in main (argc=297, argv=0x7fffffffae28) at main.cc:252

It turns out one of the object files linked contains a .interp
section. This comes from a generated C file which contains the
following line:
const char dadi_interp[] __attribute__((section(".interp"))) =
"/lib/ld-linux.so.2";

(I'm going to remove this line.)

It turns out that in the case of ld.bfd, the -dynamic-linker command
line parameter takes precedence over the .interp section in the object
file and ld.gold behaviour's differ. I'd say that ld.bfd's behaviour
is the more appropriate, i.e. command line args should take precedence
over anything else.

Should I report bugs for ldd and ld.gold?

Thanks,

Erwan

On Thu, Jul 31, 2014 at 8:47 PM, Cary Coutant <ccoutant@google.com> wrote:
> ELIBBAD means that the interpreter pointed to by the PT_INTERP segment
> is in the wrong format.
>
> Please run "readelf -l" (lower-case L) on the binary produced by gold,
> and check the program interpreter shows under PT_INTERP, then compare
> that with the binary produced by ld.bfd.
>
> -cary
>
>
> On Thu, Jul 31, 2014 at 6:20 AM, Erwan Legrand <lists@erwanlegrand.com> wrote:
>> Hi,
>>
>> I've stumbled upon the following problem while trying to use ld.gold
>> from binutils 2.24 to link a large project.
>>
>> When the project is linked with ld.gold, the resulting executable
>> cannot be executed: execve fails with ELIBBAD.
>>
>> When linking with ld.bfd, everything works as expected.
>>
>> I have made a few searches and did not find anything relevant. Is this
>> a know issue? If not, is there anything I can do to help find the root
>> cause?
>>
>> Regards,
>>
>> E.L.