Re: ld.so binding time

[Yubin Ruan <ablacktshirt at gmail dot com>]

2017-08-01 22:57 GMT+08:00 Orlando Arias <orlandoarias@gmail.com>:
> Greetings,

Many thanks! Sorry for the late reply.

> 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.

This explanation make sense ;-)

> Even if it was mapped as executable, it would still be undefined behaviour,
> since there is no actual code there to be executed.

That I don't understand. If "there is no actual code there to be executed", how
could my second example (i.e., the `open_hook') succeed? You see, the
`open_hook' pointer is changed in the __attribute__((constructor)), dynamically.

> 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.

Hmm... Not quite understand. If would be better if you can provide
some examples.

Thanks,
Yubin

>
> 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
>>
>