This is the mail archive of the binutils@sourceware.org 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]

ld.so binding time


Hi,

I am curious the binding time of ld.so when it try to resolve a
symbol. I got an simple example in a shared lib:

typedef int (*open_t) (const char *pathname, int flags, ...);

open_t open = NULL;

__attribute__((constructor))
void __theconstructor(void)
{
    open = some_function;
}

int some_function(const char *pathname, int flags, ...)
{
    ...
}

and I compile this to a .so file, and then use LD_PRELOAD to preload
it before every program startup, so that when a test program use
`open' it would use the customized `open' system call.

However, whenever I test this I got a segfault... But when I change
that to this:


typedef int (*open_t) (const char *pathname, int flags, ...);

open_t open_hook = NULL;

__attribute__((constructor))
void __theconstructor(void)
{
    open_hook = some_function;
}

int open(const char *pathname, int flags, ...)
{
    ...
    open_hook(...);
    ...
}

Things work well. So I am wondering, maybe the linker resolve symbol
at the very first startup, so that a `open' call in the test program
is resolved to NULL and I got segfault (even if I change `open' to
point to other place after __constructor__ is called), whereas in the
second example things works fine.

Is that correct? Any feedback is welcome!

Thanks,
Yubin


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