Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

On 04/30/2012 01:26 PM, Andrew Bernat wrote:
> Address bounds. Since there is no reason to have a single contiguous
> code region, I would suggest returning a vector of (start, end)
> pairs.

Hmm.  It seems like in practice (at least for Linux/ELF), there's
usually only one code region, but I suppose that's not necessary by
specification.

So I think for multiple address regions to be useful, we'll also need to
know how that relates to the file in question.  Perhaps simplest is to
turn it into a (start, end, file_offset) tuple.

This encroaches on the whole ELF Phdr struct, but I know you'll want to
stay more platform neutral than that.

Is it easier to keep a single BPatch_object per file, which has to
possibly represent multiple mappings?  Or maybe it would make sense to
have a 1:1 relation with object to mappings, even when the same file is
mapped in multiple pieces.  The same file can legally even be mapped
entirely in many separate places, even if that's not normal practice.

Perhaps this isn't BPatch_object any more, but a BPatch_mapping that
contains (file, offset, start, end, etc.).  This may be more
representative of how things are actually loaded in memory.

Thoughts?

Josh