Hrm. I'm presuming that you mean, quite precisely, modifying the
pro/epilogue blocks' contents, not augmenting them? Otherwise function
wrapping would do the trick quite nicely, as would various normal
snippet-based approaches--parameter, return, and local variable
snippets should provide most of the access to existing abstractions
you'd need. In fact, unless your problem is specifically concerned
with modifying the stack/heap/registers as actual locations, rather
than modifying the variables etc that are stored in them, I would be
quite surprised if you can't recast a problem of "modification of
prologue and epilogue" as instrumentation and not modification.
No, I am not trying to modify the stack location - instead, I am trying
to modify the size of the stackframe, by storing an additional variable
on it - right before all local variables are placed on the stack. I
guess I have to look into more detail of the BPatchAPI usage of
registers: It would be of course much easier to have abstractions of the
actual registers, such as %ebp and %esp.
You're of course right that if the call target is a binary blob
without an associated ST_FUNCTION (or if the library containing it is
not in the current address space), the function won't exist at the
BPatch level. If the library is present and you've shoved a public
symbol in, it doesn't matter whether the function in question is
assembly or a high-level language; it should be accessible at the
BPatch layer and inserting a call snippet should work.
Did I understand you correctly, that the library containing the target
function must be in the same address space - which means that it won't
work if the library is loaded with help of BPatchAPI's function
loadLibrary(lib, true)? Is there any possibility to somehow 'merge' the
address spaces between the binary and the libarry to be loaded with help
of BPatchAPI?
Thank you.
Best regards,
Sergej
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}