This is the mail archive of the
mailing list for the binutils project.
Re: ld.so binding time
2017-08-01 22:57 GMT+08:00 Orlando Arias <firstname.lastname@example.org>:
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
> On 08/01/2017 04:08 AM, Yubin Ruan wrote:
>> 2017-08-01 16:04 GMT+08:00 Andreas Schwab <email@example.com>:
>>> On Aug 01 2017, Yubin Ruan <firstname.lastname@example.org> 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.