tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Patching symbols after tcc_relocate


From: Henry Weller
Subject: Re: [Tinycc-devel] Patching symbols after tcc_relocate
Date: Sun, 10 Feb 2013 11:11:49 +0000
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/24.2 (x86_64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Hi Jared,

> I can think of one way that you can do it with TCC right now, but it
> somewhat changes your goal. What you do is that the initial definition
> of "add" is for a function that calls a function pointer. You then
> change the target of the function pointer.

> Frankly, I would just write the code to access the pointer directly
> instead. It does the same thing, but without all of the potential
> breakage.

I have thought about this but as you say it is not my goal.  What I want is to
be able to change the compiled executable in ways which do not affect the
dependencies without having to unlink recompile and relink the dependency chain
as required by dlopen/dlclose.  I.e. if a function body is changed without
change in its interface it should be possible to plug the new function in
directly replacing the original as demonstrated by ELF-Hook.

> In short, write yourself some dispatcher & redirection code that uses
> atomic reads/writes to access function pointers, instead of trying to
> redirect at the TCC level. Doing this at the C-level is far wiser than
> the path you're currently considering.

This requires significant change to the operation of the executable for all
functions whether they are over-ridden or not which is an overhead I am not
prepared to accept.  What I want is to be able to have a REPL for an executable
which is as efficient as possible.  If this is not going to be possible within
libtcc then I will live with ELF-Hook but given that it is possible for DLs I
see no reason why it is not possible from libtcc after relocation.

-- 
Best regards,

Henry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]