On Apr 30, 2012, at 4:15 PM, Josh Stone wrote:
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.
The normal is .text. However, if we ever want to represent rewritten binaries, we'll need more than that.
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.
That information can be gathered with SymtabAPI, and I want to duplicate as little as possible.
In fact, SymtabAPI will give code region information. Is there any reason for BPatch_object to not just support function lookup by address, and elide the whole problem of address bounds?
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.
I'd prefer to keep BPatch_object. The idea of BPatch_mapping is a very raw interface and can be satisfied by SymtabAPI, as I mentioned above.
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}