In need of help to understand the program behaviour while loading shared libraries and at linking time.

In need of help to understand the program behaviour while loading shared libraries and at linking time.

[ShriHari]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

Dear GCC community,

I was working on making an interception library; which I pre-load before
I run the application that I need to use it for. This is intended to
perform some redirection for logging purposes.
In my library, I have the *__attribute__ constructor(()) *to set up the
logging environment that is needed to be run *before *any resolutions to
the calls defined in my library are made.
Now, my assumption was that at runtime, this constructor will be called
before any resolutions have been made to the functions that I have defined
in this library. For example, let's say that I was intercepting the
*ioctl *function.
My assumption was that the dynamic linker would only resolve any calls (and
call them) ONLY after the *__attribute__ constructor(())* has run; or
at-least run the *ctor *when it is found. But to my surprise, it happens to
be the case that the *ctor *is delayed (17-30 milliseconds).
I have made attempts to understand the stuff that happens between the
program getting loaded, but it was challenging to come to any conclusion. I
did watch a cppCon talk by Matt Godbolt which helped me understand the
specifics at this low-level, but I am afraid that I do not understand this
totally. I am a newbie into low-level systems programming, and I am loving
to work on this. Could I please have resources to understand this behaviour
from the community? It would also be great if there is any resolution (or
is it UB) to the behaviour that I asked about.

Thank you so much for your time, and for making the world a better place
with GCC. I truly appreciate it!

Thanks and Regards,
Shrihari H

Re: In need of help to understand the program behaviour while loading shared libraries and at linking time.

[Florian Weimer]

> Now, my assumption was that at runtime, this constructor will be called
> before any resolutions have been made to the functions that I have defined
> in this library. For example, let's say that I was intercepting the
> *ioctl *function.

I'll assume your question is about GNU/Linux and therefore glibc.

That is not how this works.  Relocation completes for all objects, and
only then ELF constructors are invoked.  This two-pass approach is
necessary because otherwise, it would be more likely that unrelocated
code is executed if symbol interposition or underlinking is in play.

If you want to run your own code before relocation processing, you
should look at LD_AUDIT and audit modules.  The Solaris documentation
mostly applies to glibc as well, at least as far as the basics are
concerned.

Thanks,
Florian