Re: Dynamically wrap non dynamic symbol

[Christian Gagneraud <chgans at gmail dot com>]

On 21 September 2017 at 18:53, Andreas Schwab <schwab@suse.de> wrote:
> On Sep 21 2017, Christian Gagneraud <chgans@gmail.com> wrote:
>
>> Currently the executable code contains eg "callq 0xc15" when calling
>> one of this private symbol. I would prefer to have a call into the
>> PLT.
>
> The linker is too late in the process.  That change must be made at the
> assembler level the latest, if not in the compiler.

It's too late for the runtime linker, but for the build time linker,
something can surely be done.

Consider 3 files:
- foo.cpp
- bar.cpp
- main.cpp

main() uses Bar and Bar inherits Foo. When the compiler is run on any
of these files, it has no clue where other's unit symbol are/will be
located, it has even no clue if it's a dynamic symbol or not (it is
only aware of the class declaration).

So bar.o cannot contains things like "callq 0xc15" , where 0xc15 is
the offset within the segment that point to, say to Foo::baz(). It
doesn't even know if the symbol is provided in another .o, .a or .so.

So the build-time linker has to manage this. It is the only one that
is given a set of .o, .a or .so and then sort out the call convention
for a given symbol (local or shared).

So, is there any magic ld option, that could tell it to consider any
local symbol as if they were dynamic?
Even if there was, the dynamic linker might not be able to manage such
a weird ELF object

I'm starting to think about a vtable injector as an alternative.

Chris


>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."