gdb-6.6, faking a shared library

gdb-6.6, faking a shared library

[jbbachky]

I've got an arm program which makes use of a non-standard shared 
library and I'm looking for ways to inform gdb that it really is a 
shared library.

What I'm calling a shared library is a subset of glibc which gets 
linked/mapped to a specific address, and the programs which "link 
against it" really link against fixed addresses, thus no dynamic 
linking is involved. Special startup code is used to map the library's 
addresses for each process which need it. However, since gdb knows 
nothing about it being shared among other processes (not simply other 
pthreads sharing the same memory map), bad things happen when a 
breakpoint in that library is hit by another process.

Any ideas for making gdb think that a certain address range is a shared 
library? My glibc (v2.2.3) is NOT built for pic/dynamic linking. Thus 
no libthread_db is built. Compiler is gcc v3.4.3, linux is 2.6.10 for 
ARM.

Thanks, John
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and 
industry-leading spam and email virus protection.

Re: gdb-6.6, faking a shared library

[Daniel Jacobowitz]

On Wed, Nov 29, 2006 at 10:44:06AM -0500, jbbachky@aim.com wrote:
> What I'm calling a shared library is a subset of glibc which gets 
> linked/mapped to a specific address, and the programs which "link 
> against it" really link against fixed addresses, thus no dynamic 
> linking is involved. Special startup code is used to map the library's 
> addresses for each process which need it. However, since gdb knows 
> nothing about it being shared among other processes (not simply other 
> pthreads sharing the same memory map), bad things happen when a 
> breakpoint in that library is hit by another process.

It won't help you to tell GDB that it's a shared library; GDB inserts
breakpoints in shared libraries the same way it does anywhere else.
The debug agent is usually responsible for handling places which need
special breakpoint handling.  I think you'd need the kernel to do
breakpoint insertion/removal at context switches in the case you've
described.

-- 
Daniel Jacobowitz
CodeSourcery