On 04/26/2012 12:01 PM, Andrew Bernat wrote:
On Apr 26, 2012, at 12:54 PM, Josh Stone wrote:
bsolutely - discussion about both the idea and design are welcome.
It's quite small so far - just a few wrapped methods of mapped_object,
and an addition to enumerate objects in an image. I'm sure there are
plenty of other methods that would make sense, as well as callbacks as
mmap/munmap occur, but this is an easy and useful starting point.
Interesting choice of initial methods. Can you give a quick rationale
for why you want some of them - the address bounds in particular? I'm
somewhat surprised you began from mapped_object instead of generalizing
BPatch_module. That's not to say it's a bad idea, just not the way I had
been thinking of it. I think a merge of the two is probably what we want
in general.
For my use case, whether it's predefined SDT or addresses determined by
systemtap's own debuginfo analysis, I basically have a list of
file+address pairs that I wish to probe. So the names (esp. fullname)
let me match the file, and the address and sharedlib functions let me
figure out address relocations if needed.
As for generalizing BPatch_module, I thought modifications of those
semantics would be more controversial. I find that module abstraction
kind of weird, where it seems to mean compilation-unit in some cases, or
the whole file in other cases. But the mapped_object seems to be
exactly what information I was going for: files and where they live.
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}