On 04/28/2014 05:57 PM, Sergej Proskurin wrote:
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.
Functionally equivalent (at least re: what we do/don't allow); you're
trying to allocate space specifically on the stack. There are quite a
few ways to go about this, but none of them are through the BPatch
interface as it currently exists. You may find it easier to extend the
BPatch interface instead of working with raw bits--I can see several
different abstractions that could readily represent what you're doing
(depending on the details), and having free access to Dyninst internals
in the implementation could simplify your life greatly.
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?
Should still work (that's the point of loadLibrary). Everything that
falls under a single BPatch_binaryEdit is fair game to use.
Thank you.
Best regards,
Sergej
--
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}