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

[Marc Khouzam]

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

I very much agree with you.  
 
And that is really what we need
on the frontend side.  I'll probably have to force such a behavior
(by suspending a thread, planting the bp, and resuming) 
if GDB does not provide it directly.

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

I'm just surprised that GDB returns an ^error, and still shows the breakpoint
in the list.  If the bp was <PENDING> I don't believe GDB would have returned
an ^error.

> 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

What is the value of have a bp shown with an Error?  Will that bp ever
work?  Why should it be kept around?
What I noticed is that even after the main thread stops, in my test,
the failed bp still does not hit.  So, I'm wondering of it usefulness.
 
Thanks
 
Marc