Pending breakpoints

Pending breakpoints

[Nick Roberts]

I still think "info break" isn't quite right for pending breakpoints.  This
isn't about previous behaviour, just missing infoemation.  Currently:

   (gdb) b sqrt
   Function "sqrt" not defined.
   Make breakpoint pending on future shared library load? (y or [n]) y

   Breakpoint 1 (sqrt) pending.
   (gdb) info break
   Num     Type           Disp Enb  Address    What
   1       breakpoint     keep y    <PENDING>  sqrt
      (gdb) start
   Breakpoint 2 at 0x804862c: file myprog.c, line 95.
      Starting program: /home/nickrob/myprog 
   main (argc=1, argv=0xbff1d1e4) at myprog.c:95
   95      main (int argc, char **argv) {
   (gdb) info break
   Num     Type           Disp Enb  Address    What
   1       breakpoint     keep y    0xb7f52114 <sqrt+4>
   (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.

The patch below does that.  It's a bit of a guess, though, and I've not run
the testuite.

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


*** breakpoint.c	26 Feb 2008 21:24:24 +1300	1.303
--- breakpoint.c	26 Feb 2008 22:42:54 +1300	
*************** static void print_breakpoint_location (s
*** 3311,3317 ****
        
        ui_out_field_int (uiout, "line", b->line_number);
      }
!   else if (!b->loc)
      {
        ui_out_field_string (uiout, "pending", b->addr_string);
      }
--- 3311,3317 ----
        
        ui_out_field_int (uiout, "line", b->line_number);
      }
!   else if (!b->loc || loc->shlib_disabled)
      {
        ui_out_field_string (uiout, "pending", b->addr_string);
      }

Re: Pending breakpoints

[Daniel Jacobowitz]

On Wed, Feb 27, 2008 at 09:14:23AM +1300, Nick Roberts wrote:
> 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

When you kill the program, for instance.  I think GDB holds on to the
last set of shared libraries, currently, but it shouldn't.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Pending breakpoints

[Daniel Jacobowitz]

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Pending breakpoints

[Nick Roberts]

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

Re: Pending breakpoints

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

>     (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.

Why is that a problem?  They started out this way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Pending breakpoints

[Daniel Jacobowitz]

On Thu, Apr 03, 2008 at 11:00:35PM +1200, Nick Roberts wrote:
>     -6      longjmp        keep n   0xb7da7be0 <siglongjmp>
>     -7      longjmp        keep n   0xb7da7be0 <siglongjmp>
>     -8      longjmp        keep n   0xb7da7be0 <siglongjmp>

Actually this is the one I consider a problem; it's weird that we look
up the symbol name for this.  We set breakpoints on longjmp and
_longjmp and siglongjmp just in case they're different.  And that
predates your change.

>  > 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?

I hope so.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Pending breakpoints

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Thu, Apr 03, 2008 at 11:00:35PM +1200, Nick Roberts wrote:
>>     -6      longjmp        keep n   0xb7da7be0 <siglongjmp>
>>     -7      longjmp        keep n   0xb7da7be0 <siglongjmp>
>>     -8      longjmp        keep n   0xb7da7be0 <siglongjmp>
> 
> Actually this is the one I consider a problem; it's weird that we look
> up the symbol name for this.  We set breakpoints on longjmp and
> _longjmp and siglongjmp just in case they're different.  And that
> predates your change.
> 
>>  > 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?
> 
> I hope so.

Then, we won't have any place to remember if any individual location is
enabled or disabled.

- Volodya