This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux
> > 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