hacking shlib/dlopened breakpoints

hacking shlib/dlopened breakpoints

[Caolan McNamara]

I'm looking at breakpoints in dlopened libraries at the moment,
setting a breakpoint after my library is dlopened works of course
and, as in the example below, I see that gdb can move the address of
the breakpoint in the .so when it is unloaded and reloaded during
execution, but on re-execution of the little program I get
"
Warning:
Cannot insert breakpoint X.
Error accessing memory address 0xe8535a: Input/output error.
"

Naturally the library isn't loaded at the start of re-execution, but I
hoped that the the breakpoint state would change to bp_shlib_disabled
and get reenabled when the .so reappears.

So I dig a little and see that this will only happen if
(DISABLE_UNSETTABLE_BREAK (b->address)) is true. But that queries to
see if the address is a valid loaded address, which it isn't anymore.
I naively turned this to if (1) to see what would happen, and was
happy to see this worked, the breakpoint in the .so gets re-enabled
and set to its new address when the affected .so reappears, and gdb
stops in it correctly. 

But sadly when I continue everything only works as far as the dlclose
of that .so where I get...
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x008c4ea4 in _dl_debug_state_internal () from /lib/ld-linux.so.2

Any ideas/hints as to how to make it work, or what exactly might the
cause of my exciting crash above ? The reason I'm fiddling with this
is that I'm really after a working deferred break/future-break in gdb
to make debugging apps like OpenOffice/Mozilla with mountains of
dynamically loaded components a lot easier.

C.

Sample program/lib and patch follow...

/*---main.c--- start*/
#include <stdio.h>
#include <dlfcn.h>
                                                                                
int main(int argc, char **argv)
{
    void *handle;
    double (*cosine)(double);
    char *error;
    int i;
                                                                                
    for (i = 0; i < 3; ++i)
    {
        handle = dlopen ("./libfoo.so", RTLD_LAZY);
        if (!handle)
        {
            fprintf (stderr, "%s\n", dlerror());
            exit(1);
        }
                                                                                
        cosine = dlsym(handle, "fakecos");
        if ((error = dlerror()) != NULL)
        {
            fprintf (stderr, "%s\n", error);
            exit(1);
        }
                                                                                
        printf ("%f\n", (*cosine)(2.0));
        dlclose(handle);
    }
                                                                                
    return 0;
}
/*---main.c--- end*/
/*---libfoo.c--- start*/
double fakecos(double f)
{
    return 100.0;
}
/*---libfoo.c--- end*/
                                                                                
gcc -g -rdynamic main.c -ldl
gcc -g -shared -nostartfiles -o libfoo.so
                                                                                
                                                                                
diff -u -r gdb-6.0/gdb/breakpoint.c gdb-6.0.stage1/gdb/breakpoint.c
--- gdb-6.0/gdb/breakpoint.c    2003-07-02 17:24:30.000000000 +0100
+++ gdb-6.0.stage1/gdb/breakpoint.c     2003-11-19 16:30:44.000000000 +0000
@@ -854,7 +854,7 @@
          {
            /* Can't set the breakpoint.  */
 #if defined (DISABLE_UNSETTABLE_BREAK)
-           if (DISABLE_UNSETTABLE_BREAK (b->address))
+           if (1)
              {
                /* See also: disable_breakpoints_in_shlibs. */
                val = 0;
-- 
Caolan McNamara               |  caolan@skynet.ie  
http://www.skynet.ie/~caolan  |  +353 86 8161184
Once my power is secure, I will destroy all those pesky time-travel devices

Re: hacking shlib/dlopened breakpoints

[Daniel Jacobowitz]

On Fri, Nov 21, 2003 at 12:55:02PM +0000, Caolan McNamara wrote:
> I'm looking at breakpoints in dlopened libraries at the moment,
> setting a breakpoint after my library is dlopened works of course
> and, as in the example below, I see that gdb can move the address of
> the breakpoint in the .so when it is unloaded and reloaded during
> execution, but on re-execution of the little program I get
> "
> Warning:
> Cannot insert breakpoint X.
> Error accessing memory address 0xe8535a: Input/output error.
> "
> 
> Naturally the library isn't loaded at the start of re-execution, but I
> hoped that the the breakpoint state would change to bp_shlib_disabled
> and get reenabled when the .so reappears.
> 
> So I dig a little and see that this will only happen if
> (DISABLE_UNSETTABLE_BREAK (b->address)) is true. But that queries to
> see if the address is a valid loaded address, which it isn't anymore.
> I naively turned this to if (1) to see what would happen, and was
> happy to see this worked, the breakpoint in the .so gets re-enabled
> and set to its new address when the affected .so reappears, and gdb
> stops in it correctly. 

Could you try a current CVS snapshot?  I just made a change in this
area to fix another problem with dlopen'd librares.

> But sadly when I continue everything only works as far as the dlclose
> of that .so where I get...
> Program received signal SIGSEGV, Segmentation fault.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0x008c4ea4 in _dl_debug_state_internal () from /lib/ld-linux.so.2
> 
> Any ideas/hints as to how to make it work, or what exactly might the
> cause of my exciting crash above ? The reason I'm fiddling with this

Probably something else was loaded over the same space.  Or GDB's
breakpoint list got hosed.

> is that I'm really after a working deferred break/future-break in gdb
> to make debugging apps like OpenOffice/Mozilla with mountains of
> dynamically loaded components a lot easier.

See Jeff's recent post on this topic...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: hacking shlib/dlopened breakpoints

[H. J. Lu]

On Fri, Nov 21, 2003 at 12:55:02PM +0000, Caolan McNamara wrote:
> I'm looking at breakpoints in dlopened libraries at the moment,
> setting a breakpoint after my library is dlopened works of course
> and, as in the example below, I see that gdb can move the address of
> the breakpoint in the .so when it is unloaded and reloaded during
> execution, but on re-execution of the little program I get
> "
> Warning:
> Cannot insert breakpoint X.
> Error accessing memory address 0xe8535a: Input/output error.
> "
> 
> Naturally the library isn't loaded at the start of re-execution, but I
> hoped that the the breakpoint state would change to bp_shlib_disabled
> and get reenabled when the .so reappears.
> 

Is there a way to tell gdb to stop right after the symbols of a
dlopened DSO is loaded?


H.J.

Re: hacking shlib/dlopened breakpoints

[Daniel Jacobowitz]

On Fri, Nov 21, 2003 at 11:15:21AM -0800, H. J. Lu wrote:
> On Fri, Nov 21, 2003 at 12:55:02PM +0000, Caolan McNamara wrote:
> > I'm looking at breakpoints in dlopened libraries at the moment,
> > setting a breakpoint after my library is dlopened works of course
> > and, as in the example below, I see that gdb can move the address of
> > the breakpoint in the .so when it is unloaded and reloaded during
> > execution, but on re-execution of the little program I get
> > "
> > Warning:
> > Cannot insert breakpoint X.
> > Error accessing memory address 0xe8535a: Input/output error.
> > "
> > 
> > Naturally the library isn't loaded at the start of re-execution, but I
> > hoped that the the breakpoint state would change to bp_shlib_disabled
> > and get reenabled when the .so reappears.
> > 
> 
> Is there a way to tell gdb to stop right after the symbols of a
> dlopened DSO is loaded?

set stop-on-solib-events 1

There's a documented catch load command, but it only works on HP/UX. 
Fixing it for SysV shared libraries is somewhere down my list of things
to do.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer