Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

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.

Thus BPatch_object : mapped_object :: BPatch_module : mapped_module, or
so I was going for.  It seems to me like a simple and safe addition.
But if you envision some greater merger/cleanup of functionality, by all
means, let's hear it.

> As a personal note, we'll want to do some method renaming. Many Dyninst
> developers (including me, in the past) have been fans of the
> ReallyLongFunctionNameMethod, but "name" works just as well. 

Sure, paint the bike shed whatever color you consider fashionable. ;)

For the calling signature of getFileName and getFullName, I'd prefer to
just return std::string, actually, rather than a messy buffer+length,
but I was following the style of BPatch_module there.  Perhaps that's
just historic/antiquated too...

Josh