Re: Pending breakpoints

[Nick Roberts <nickrob at snap dot net dot nz>]

Daniel Jacobowitz writes:
 > On Wed, Feb 27, 2008 at 09:14:23AM +1300, Nick Roberts wrote:
 > >    (gdb) nosharedlibrary 
 > >    (gdb) info break
 > >    Num     Type           Disp Enb  Address    What
 > >    1       breakpoint     keep y    <PENDING>  
 > > 
 > > and the last "info break" no longer says what the breakpoint is for.  I don't
 > > really know when you would unload the shared library, in practice, but I think
 > > this line should look like the first output from "info break", i.e., include
 > > sqrt.
 > 
 > I agree that this is wrong.
 > 
 > > The patch below does that.  It's a bit of a guess, though, and I've not run
 > > the testuite.
 > 
 > Seems good to me.  We do the same in print_one_breakpoint_location.
 > The patch is OK with a changelog and a full test run.

Actually I better leave this alone because I don't know what I'm doing
and I can see problems:

    This GDB was configured as "i686-pc-linux-gnu"...
    (gdb) start
    Breakpoint 1 at 0x804862c: file myprog.c, line 135.
    Starting program: /home/nickrob/myprog 
    main (argc=1, argv=0xbfc4cf14) at myprog.c:135
    135     main (int argc, char **argv) {
    (gdb) kill
    Kill the program being debugged? (y or n) y
    (gdb) maint inf bre
    Num     Type           Disp Enb Address    What
    -3      shlib events   keep y   0xb7f02c10 <_dl_debug_state>
            breakpoint already hit 2 times
    -6      longjmp        keep n   0xb7da7be0 <siglongjmp>
    -7      longjmp        keep n   0xb7da7be0 <siglongjmp>
    -8      longjmp        keep n   0xb7da7be0 <siglongjmp>
    -9      longjmp resume keep n   0x00000000 
    (gdb) inf sha
    warning: Temporarily disabling breakpoints for unloaded shared library "/lib/tls/i686/cmov/libc.so.6"
    From        To          Syms Read   Shared Object Library
    0xb7ef57f0  0xb7f09cff  Yes         /lib/ld-linux.so.2
    (gdb) maint inf bre
    Num     Type           Disp Enb Address    What
    -3      shlib events   keep y   0xb7f02c10 <_dl_debug_state>
            breakpoint already hit 2 times
    -6      longjmp        keep n   <PENDING>  longjmp
    -7      longjmp        keep n   <PENDING>  _longjmp
    -8      longjmp        keep n   <PENDING>  siglongjmp
    -9      longjmp resume keep n   0x00000000 
    (gdb) 

And breakpoints -6,-7 and -8 are associated with three different functions
even though they have the same address.

 > Even better would be to discard locations when we shlib_disable a
 > breakpoint, and get rid of the shlib_disable flag.  But doing that may
 > require that we get rid of shared libraries when we're supposed to.

Would that `solve' this problem?


-- 
Nick                                           http://www.inet.net.nz/~nickrob