Re: [DynInst_API:] BPatch_object


Date: Mon, 07 May 2012 16:42:36 -0700
From: Josh Stone <jistone@xxxxxxxxxx>
Subject: Re: [DynInst_API:] BPatch_object
On 05/07/2012 01:02 PM, Andrew Bernat wrote:
> I've attached a patch for a first stab at a BPatch_object. The 
> interface is pretty spartan at the moment, but if I recalled 
> correctly it will give you everything you need to have.

It looks like you already pushed this to master, so I just tested on
that code directly.

> As with BPatch_modules, a BPatch_object is accessed from the 
> BPatch_image. Instead of putting in a by-name or by-address lookup, 
> you just get the full list (for now).

This is fine.  I think we'll also want a callback for dlopen/dlclose
type of events, so one can see objects that come and go.

> Objects support converting an offset to an address, creating points, 
> and looking up functions.
==>
> +Dyninst::Address BPatch_object::offsetToAddrInt(const Dyninst::Offset offset) {
> +   if (offset >= obj->imageOffset() &&
> +       offset < (obj->imageOffset() + obj->imageSize())) {
> +      return offset + obj->codeAbs();
> +   }
> +   if (offset >= obj->dataOffset() &&
> +       offset < (obj->dataOffset() + obj->dataSize())) {
> +      return offset + obj->dataAbs();
> +   }
> +   
> +   return E_OUT_OF_BOUNDS;
> +}

I think this is not quite correct.  I'm seeing that imageOffset() and
dataOffset() are returning large numbers, apparently the actual load
addresses.  This may be because most of my system libraries are already
prelinked.  But if the offset parameter is meant to be a *file* offset,
then this range check doesn't make sense.

Note it's not just prelinked libraries, though, the main ET_EXEC binary
is also showing me a large imageOffset(), typically 0x400000.  As it
happened, I actually had absolute addresses in this case, so they did
pass this range check, but then the returned address +codeAbs() is too
big, so findPoints fails.

> Let me know if there is any additional functionality you need.

The ET_EXEC thing also reminds me why I created isSharedLib() before.
It's pretty common with these to deal in absolute addresses, rather than
file+offset, so I was using isSharedLib to decide whether relocation was
needed.  In this new world, it would similarly help me decide whether an
offsetToAddr call is needed.

That's me being a little bit lazy, though -- I could also make sure to
always generate file-relative addresses, so it's always expected to be
converted.  In fact, I'll go ahead and do that in my client code.  It
still may be an interesting property for BPatch_object, is it EXEC/DYN.

Josh
[← Prev in Thread] Current Thread [Next in Thread→]