ld.so binding time

[Orlando Arias]

Greetings,

No, ld.so is doing exactly what it is supposed to do. It resolves the
symbol and populates the GOT as expected. The problem here is that you
are telling ld.so to resolve an open that is of type open_t (a pointer
[also, in POSIX this is a reserved name]). When the dynamic linker goes
on to resolve your symbol, it will populate the GOT with the address of
open. Looking at your code, this should be in an area that is mapped
readable and writable. When you then issue a call to open, the address
that will be loaded from the GOT will be that of your symbol. The PLT
entry will then jump to that address and attempt to execute from there.
Since that memory is not mapped as executable, you SIGSEGV. Even if it
was mapped as executable, it would still be undefined behaviour, since
there is no actual code there to be executed.

And no, you can not make ld.so dereference the pointer as you want it
to. Otherwise, it would not be able to resolve other symbols of similar
types as it would be expected to do.

Cheers,
Orlando.

On 08/01/2017 04:08 AM, Yubin Ruan wrote:
> 2017-08-01 16:04 GMT+08:00 Andreas Schwab <schwab@suse.de>:
>> On Aug 01 2017, Yubin Ruan <ablacktshirt@gmail.com> wrote:
>>
>>> So, for the `open' symbol,
>>>     open_t open;
>>
>> This is a pointer.
>>
>>> is different from
>>>     int open(const char *pathname, int flags, ...);
>>
>> This is a function.
> 
> If those are two different types, then why would ld.so resolve a
> `open()' system call to a pointer and then make it throw a segfault?
> If those are two different types, then I think ld.so should bypass my
> "customized pointer". But it seems not to be the case.
> 
> Yubin
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20170801/61fe6c3d/attachment.sig>