This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binding time

2017-08-01 22:57 GMT+08:00 Orlando Arias <>:
> Greetings,

Many thanks! Sorry for the late reply.

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


> On 08/01/2017 04:08 AM, Yubin Ruan wrote:
>> 2017-08-01 16:04 GMT+08:00 Andreas Schwab <>:
>>> On Aug 01 2017, Yubin Ruan <> 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 resolve a
>> `open()' system call to a pointer and then make it throw a segfault?
>> If those are two different types, then I think should bypass my
>> "customized pointer". But it seems not to be the case.
>> Yubin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]