Re: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux

[Pedro Alves <pedro@codesourcery.com>]

On Friday 01 May 2009 20:31:21, Marc Khouzam wrote:

> I'm using HEAD (from yesterday) with Non-Stop locally on Linux.
> I notice that when all my threads are running, setting a breakpoint
> is misbehaving.
> 
> First, should I be able to set a breakpoint when all threads
> are running (on Linux)?

I've worked with non-stop mode in a few targets other than linux
already, and so far, only linux has this issue, and it
is *really* a nuisance.  I've been thinking we should make it
possible on linux to insert breakpoints when threads are running
as well.  The user experience is just bad otherwise.

> Either way though, setting a bp reports an error -with-
> a breakpoint id, and then 'info break' shows the breakpoint
> as being set.  However, the breakpoint does not actually hit.
> 
> See below for the session.


> 
> (gdb) 
> info b
> &"info b\n"
> ~"Num     Type           Disp Enb Address    What\n"
> ~"1       breakpoint     keep y   0x080485dc in main at
> MultiThread.cc:24\n"
> ~"2       breakpoint     keep y   0x0804857a in thread_exec(void*) at
> MultiThread.cc:10\n"
> ~"3       breakpoint     keep y   0x0804857e in thread_exec(void*) at
> MultiThread.cc:11\n"
> ^done
> 
> == Both 'failed' breakpoints show as installed, but they ==
> == don't actually stop the thread.                       ==

I don't think this output indicates the breakpoints are installed or not. 
"Enb" is a high level user setting; The "Address" field showing a resolved address
means that GDB is sure of the breakpoint address and believes those addresses
belong to currently mapped memory area --- if the breakpoints that failed
to insert pointed at code in a shared library, GDB would have made the
breakpoint locations pending (<PENDING>), because it would assume that
the reason the insertion failed was due to the shared library having
been unloaded.  But, GDB doesn't do that for breakpoints set in
the main executable -- only in shlibs.

What would people think of adding a new column in "info breakpoints" showing
the "inserted" status of the breakpoint?  It should be used to
show 'inserted', 'not inserted', 'not inserted due to error' state,
and perhaps more states.

E.g.:

 Num     Type           Disp Enb Ins Address    What
 1       breakpoint     keep y   y   0x080485dc in main at MultiThread.cc:24
 2       breakpoint     keep y   n   <PENDING>  at foo
 3       breakpoint     keep y   E   0xaaff8f45 at foo2

?

-- 
Pedro Alves