Mon Feb 13 19:22:00 GMT 2017
On 2017-02-13 19:52, Florian Weimer wrote:
> On 02/13/2017 02:31 PM, Carlo Kok wrote:
>> The call it fails at is _start, specifically:
>> callq __libc_start_main@PLT
>> from gdb it looks like:
>> 0x000000000026a9b4 <+36>: callq 0x26e860
>> Goes here:
>> => 0x000000000026e860 <+16>: jmpq *0xd72(%rip) # 0x26f5d8
>> Goes to 0x0000000 (LD_BIND_NOW=1)
> That's probably an unrelated issue caused by LD_BIND_NOW, so it's not
> worth debugging that.
>> Without LD_BIND_NOW=1 the jmpq jumps over itself and calls what seems to
>> be symbol loading code, fails with an error, either way it never seems
>> to go into libc_start_main.
> Sorry, I don't know how to debug this further without access to the
> binaries and single-stepping through the dynamic linker.
Wasn't sure that the policy was on sending executables here so I didn't
originally. It's pretty much a test of my compiler to dynamic library
support. (None of the code gets called at this point since it fails
before entering libc_start_main)
More information about the Libc-help