[interfacekit] Re: A patch for BString
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Fri, 07 Nov 2003 20:58:56 +0100
On 2003-11-07 at 03:44:55 [+0100], you wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2003-11-06 at 11:09:30 [+0100], Oliver Tappe wrote:
>
> > > CPPUNIT_ASSERT_DEBUGGER( s.Insert( "dummy", 20));
> > > Does this kind of stuff already exist in cppunit? Is it feasible at
> > > all?
> > AFAIK, it is not implemented and at the time I hit this problem
> > myself (a
> > year or so ago) I thought it wasn't possible to solve... Now I know
> > better.
> > :-)
> > ...
> > If noone objects, I can try and extend our unit test framework to
> > support
> > testing for debugger calls.
>
> That would be great! How does it work, btw? :-)
As you probably know, ELF defines that functions in other shared objects
are invoked through entries in the PLT (procedure linkage table) of the
invoking shared object, which in turn gets the address of the symbol out of
the shared object's GOT (global offset table).
So, if a function shall be redirected, its entries in the GOTs of all
loaded images need to be adjusted accordingly. There's no entry in the GOT
of the image the symbol lives in, since invocations within an image are
done directly (not through the PLT). Hence only calls between different
shared objects can be redirected. I.e. a debugger() call from within
libroot will still invoke the original function.
In fact it should also be possible to patch intra-image invocations, but it
would be a bit more complicated. Currently it is sufficient to read the
relocation entries for the GOT from the ELF file corresponding to the image
to find out where the entries of the symbol in question are located in the
GOT. To also patch the other symbol occurrences, all relocation sections in
the file would need to be analyzed and then a way must be found to fix the
read-only area the objects code was loaded into -- I guess cloning the area
with write permission would work. Anyway, it's definitely more complicated,
and for the purpose I originally wrote it (memory allocation tracking) the
limited implementation was sufficient.
Will check the stuff in on the weekend.
CU, Ingo
- Follow-Ups:
- [interfacekit] Re: A patch for BString
- From: Ingo Weinhold
- References:
- [interfacekit] Re: A patch for BString
- From: Axel Dörfler
Other related posts:
- » [interfacekit] A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- » [interfacekit] Re: A patch for BString
- [interfacekit] Re: A patch for BString
- From: Ingo Weinhold
- [interfacekit] Re: A patch for BString
- From: Axel Dörfler