[non-stop] 00/10 non-stop mode

[non-stop] 00/10 non-stop mode

[Pedro Alves]

[ 3rd time I'm sending this.  Don't know why, but it doesn't seem
to want to go through, while the rest of the series went ok.  Maybe
because I had an attachment with .cmd extension.  Here are the
contents of the nonstop.cmd file mentioned in the body of the message:

cat /home/pedro/nonstop.cmd
# GDB Command file to turn on non-stop debugging mode.

# Enable the async interface
maint set linux-async 1

# With non-stop, breakpoints have to be always inserted
set breakpoint always-inserted 1

# If using the CLI, pagination breaks non-stop
set pagination off

# Finally, turn it on!
set non-stop 1
]



Hi,

Here goes a new series of non-stop debugging support, core
and linux native (x86, and probably PowerPC once Luis' displaced
stepping patch for PPC goes in).

The series now has no uncommited dependencies, so you
can now easilly pick it.

There are still unresolved ongoing discussions on how to
expose target support for non-stop, but that shouldn't
prevent this series to go in.

Contrary to the previous series, this series does add the
support for GDB to *not* switch threads automatically on
events (in non-stop mode), and implements the support for
exited threads.  I'd say it's in commit-state, except for
any rework due to review, of course.

MI/non-stop is our main focus, but CLI works a bit
too, although there are a few rough UI edges.

To activate nonstop mode, I use the attached nonstop.cmd
command file, with 'gdb -x nonstop.cmd program'.

I've tested the full series on x86-pc-linux-gnu
async/sync/all-stop to make sure nothing broke, and
also on arm-linux to make sure software single-stepping
didn't brake, and also on cygwin, to test at least
a non-linux target.


Here's the looks of non-stop mode in the CLI, debugging
a multi-threaded app:

(gdb) r&
Starting program: /home/pedro/gdb/tests/threads32
(gdb) [Thread debugging using libthread_db enabled]
[New LWP 23453]
[New LWP 23454]
info threads
  3 Thread 0xf7603b90 (LWP 23454)  (running)
  2 Thread 0xf7e04b90 (LWP 23453)  (running)
* 1 LWP 23450  (running)
(gdb) thread 2
[Switching to thread 2 (Thread 0xf7e04b90 (LWP 23453))] (running)
(gdb) interrupt
(gdb)
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xf7e04b90 (LWP 23453)]
0xffffe410 in __kernel_vsyscall ()
b 63
Breakpoint 1 at 0x80485a6: file threads.c, line 63.
(gdb) info threads
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) 
at 0xffffe411.
  3 Thread 0xf7603b90 (LWP 23454)  (running)
* 2 Thread 0xf7e04b90 (LWP 23453)  0xffffe410 in __kernel_vsyscall ()
  1 Thread 0xf7e056b0 (LWP 23450)  (running)
(gdb) c&
Continuing.
(gdb)
Breakpoint 1, thread_function0 (arg=0x0) at threads.c:63
63              (*myp) ++;
info threads
  3 Thread 0xf7603b90 (LWP 23454)  (running)
* 2 Thread 0xf7e04b90 (LWP 23453)  thread_function0 (arg=0x0) at threads.c:63
  1 Thread 0xf7e056b0 (LWP 23450)  (running)

(gdb) b 80
Breakpoint 2 at 0x80485f0: file threads.c, line 80.
(gdb) [Switching to Thread 0xf7603b90 (LWP 23454)]

Breakpoint 2, thread_function1 (arg=0x1) at threads.c:80
80              (*myp) ++;
info threads
* 3 Thread 0xf7603b90 (LWP 23454)  thread_function1 (arg=0x1) at threads.c:80
  2 Thread 0xf7e04b90 (LWP 23453)  thread_function0 (arg=0x0) at threads.c:63
  1 Thread 0xf7e056b0 (LWP 23450)  (running)
(gdb)                                         

-- 
Pedro Alves

Re: [non-stop] 00/10 non-stop mode

[Vladimir Prus]

Pedro Alves wrote:

> Here goes a new series of non-stop debugging support, core
> and linux native (x86, and probably PowerPC once Luis' displaced
> stepping patch for PPC goes in).
> 
> The series now has no uncommited dependencies, so you
> can now easilly pick it.
> 
> There are still unresolved ongoing discussions on how to
> expose target support for non-stop, but that shouldn't
> prevent this series to go in.

Well, I have a patch making

        -gdb-set non-stop 1

enable everything. I'll send that together with other MI
patches really soon.

- Volodya

Re: [non-stop] 00/10 non-stop mode

[Nick Roberts]

These are a great set of patches and they applied cleanly (after I sorted
out my own mistakes!).  It's odd how good posts attract little response
while trivial remarks often lead to long threads.

 > cat /home/pedro/nonstop.cmd
 > # GDB Command file to turn on non-stop debugging mode.
 > 
 > # Enable the async interface
 > maint set linux-async 1

Why is this still a maintenance command while the others aren't?

 > # With non-stop, breakpoints have to be always inserted
 > set breakpoint always-inserted 1
 > 
 > # If using the CLI, pagination breaks non-stop
 > set pagination off
 > 
 > # Finally, turn it on!
 > set non-stop 1

Does it make sense to have always-inserted without non-stop?  If not could
these two options be merged?

 > Here's the looks of non-stop mode in the CLI, debugging
 > a multi-threaded app:
 > 
 > (gdb) r&
 > Starting program: /home/pedro/gdb/tests/threads32
 > (gdb) [Thread debugging using libthread_db enabled]
 > [New LWP 23453]
 > [New LWP 23454]
 > info threads
 >   3 Thread 0xf7603b90 (LWP 23454)  (running)
 >   2 Thread 0xf7e04b90 (LWP 23453)  (running)
 > * 1 LWP 23450  (running)
 > (gdb) thread 2
 > [Switching to thread 2 (Thread 0xf7e04b90 (LWP 23453))] (running)
 > (gdb) interrupt
 > (gdb)
 > Program received signal SIGINT, Interrupt.
 > [Switching to Thread 0xf7e04b90 (LWP 23453)]
 > 0xffffe410 in __kernel_vsyscall ()

How about giving the interrupt command an argument so that

      (gdb) interrupt 2

means

      (gdb) thread 2
      (gdb) interrupt

I realise you're not really interested in CLI commands but the same change
could be made to -exec-interrupt,

 > b 63
 > Breakpoint 1 at 0x80485a6: file threads.c, line 63.

It's interesting that you can set breakpoints (presumably on all threads) when
the other threads are still running.  Given that is the case, would it make
sense to add "break" to the list of commands that can be executed while the
target is running? (using get_cmd_async_ok).  Then you wouldn't need to
interrupt a thread first.

 > (gdb) info threads
 > During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) 
 > at 0xffffe411.
 >   3 Thread 0xf7603b90 (LWP 23454)  (running)
 > * 2 Thread 0xf7e04b90 (LWP 23453)  0xffffe410 in __kernel_vsyscall ()
 >   1 Thread 0xf7e056b0 (LWP 23450)  (running)

With "info threads" (and perhaps elsewhere) I don't always get the prompt
back.  I've seen this just with async mode - I think there's some weird
interaction with readline.

Once while pressing return to get the prompt, I got a SIGTRAP which presumably
meant that GDB had thought it had removed a breakpoint when, in fact, it
hadn't.  I can't reproduce this, though.

 > (gdb) c&
 > Continuing.

The "continue" command just acts on the current thread.  I know there was a
dicussion about using "--all" and that N is used already as an ignore count,
but I suggested a separate command, "threadset", to determine which thread(s)
"continue" acts on:

  http://sourceware.org/ml/gdb/2008-03/msg00229.html

as well as being able to release and hold threads.  What do you think of these
ideas?

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

Re: [non-stop] 00/10 non-stop mode

[Pedro Alves]

A Monday 16 June 2008 23:27:47, Nick Roberts wrote:

>  > # Enable the async interface
>  > maint set linux-async 1
>
> Why is this still a maintenance command while the others aren't?
>

Because, (if you remember, we've talked about this before)there are issues 
with async mode that prevent it from being the default (core side,
not linux only).  Ideally, async mode is a superset of sync mode, so
it should always be on.  It's not something the user should need
to toggle.

> Does it make sense to have always-inserted without non-stop?  
> If not could 
> these two options be merged?
>

Maybe not merged, but have non-stop activate always-inserted?  It's
been on my list forever, but, it seems Vladimir has mentioned he
has already done something to tackle it.  I can't think
of a reason we can't live the seperate options for a bit, though.  Let's
fix that, and reporting target non-stop support on top of this series,
please.

> How about giving the interrupt command an argument so that
>
>       (gdb) interrupt 2

Actually, the first iteration of this series I posted did that, than
I removed it.  Again, I'm trying to do the minimal set of user interface
changes for now.  It's not like we can't improve things later.

>  > b 63
>  > Breakpoint 1 at 0x80485a6: file threads.c, line 63.
>
> It's interesting that you can set breakpoints (presumably on all threads)
> when the other threads are still running.  Given that is the case, would it
> make sense to add "break" to the list of commands that can be executed
> while the target is running? (using get_cmd_async_ok).  Then you wouldn't
> need to interrupt a thread first.
>

The issue is that it isn't possible in some targets to read/write memory
to a running target.  You need to be able to write memory to
insert breakpoints.  Linux/ptrace falls into this category.  It was easy
to implement momentarilly pausing the current thread to
insert breakpoints, but I ended up removing it from the series for now.

>  > (gdb) info threads
>  > During symbol reading, incomplete CFI data; unspecified registers (e.g.,
>  > eax) at 0xffffe411.
>  >   3 Thread 0xf7603b90 (LWP 23454)  (running)
>  > * 2 Thread 0xf7e04b90 (LWP 23453)  0xffffe410 in __kernel_vsyscall ()
>  >   1 Thread 0xf7e056b0 (LWP 23450)  (running)
>
> With "info threads" (and perhaps elsewhere) I don't always get the prompt
> back.  I've seen this just with async mode - I think there's some weird
> interaction with readline.
>

Right.  Someone needs to go through the async mode, and cleanup the
UI quirks.  This is not related to the non-stop mode.

> Once while pressing return to get the prompt, I got a SIGTRAP which
> presumably meant that GDB had thought it had removed a breakpoint when, in
> fact, it hadn't.  I can't reproduce this, though.
>

Ack.  I'll be in the lookout for these.  If you do come up with a
pattern that triggers this, please let me know.  I'd guess it's
related to step-resume breakpoints and it's interfacing with the
threads module.

>  > (gdb) c&
>  > Continuing.
>
> The "continue" command just acts on the current thread.  I know there was a
> dicussion about using "--all" and that N is used already as an ignore
> count, but I suggested a separate command, "threadset", to determine which
> thread(s) "continue" acts on:
>
>   http://sourceware.org/ml/gdb/2008-03/msg00229.html
>
> as well as being able to release and hold threads.  What do you think of
> these ideas?

There have been talks about something like this, and it seems to
fit into Vladimir's thread group notion.  If something like that is
implemented, the default should be current thread only anyway.

-- 
Pedro Alves

Re: [non-stop] 00/10 non-stop mode

[Nick Roberts]

 > >  > # Enable the async interface
 > >  > maint set linux-async 1
 > >
 > > Why is this still a maintenance command while the others aren't?
 > >
 > 
 > Because, (if you remember, we've talked about this before)there are issues 
 > with async mode that prevent it from being the default (core side,
 > not linux only).

In that case I'm not really sure what you mean by core - non-stop mode includes
changes to linux-nat.c, so presumably that is linux only.

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

Re: [non-stop] 00/10 non-stop mode

[Pedro Alves]

A Wednesday 18 June 2008 21:46:57, Nick Roberts wrote:
>  > >  > # Enable the async interface
>  > >  > maint set linux-async 1
>  > >
>  > > Why is this still a maintenance command while the others aren't?
>  >
>  > Because, (if you remember, we've talked about this before)there are
>  > issues with async mode that prevent it from being the default (core
>  > side, not linux only).
>
> In that case I'm not really sure what you mean by core - non-stop mode
> includes changes to linux-nat.c, so presumably that is linux only.

I don't follow where you're getting at.  Async mode requires
target support, but of course there's also code in the core of
GDB to support it.  Non-stop mode requires target support, builds
on top of the async mode, and of course needs core support too.
The async limitations are in the core side, and affect any async
target -- currently only linux and remote.

We could merge "maint set linux-async" and "maint set remote-async"
into one global "maint set async", I don't see a problem with that.

-- 
Pedro Alves

Re: [non-stop] 00/10 non-stop mode

[Nick Roberts]

 > > In that case I'm not really sure what you mean by core - non-stop mode
 > > includes changes to linux-nat.c, so presumably that is linux only.
 > 
 > I don't follow where you're getting at.  Async mode requires
 > target support, but of course there's also code in the core of
 > GDB to support it.  Non-stop mode requires target support, builds
 > on top of the async mode, and of course needs core support too.

I mean, for consistency, shouldn't it be:

maint set non-stop 1

since this option presumably also only works for linux (and remote?).
Anway, it's no big deal either way.

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

Re: [non-stop] 00/10 non-stop mode

[Pedro Alves]

A Wednesday 18 June 2008 23:21:16, Nick Roberts wrote:
>  > > In that case I'm not really sure what you mean by core - non-stop mode
>  > > includes changes to linux-nat.c, so presumably that is linux only.
>  >
>  > I don't follow where you're getting at.  Async mode requires
>  > target support, but of course there's also code in the core of
>  > GDB to support it.  Non-stop mode requires target support, builds
>  > on top of the async mode, and of course needs core support too.
>
> I mean, for consistency, shouldn't it be:
>
> maint set non-stop 1
>

Ah, I see where you're confused.   Enabling async support or not, is
something that ideally we shouldn't need to give the user
an option for.  Therefore, it's a maintainer command, that we'll
use until the reasons we have it go away.

Selecting non-stop or all-stop modes, is something the user will
want to do (even if all-stop mode gets to be implemented on top of
non-stop in the future), as both modes are useful.

> since this option presumably also only works for linux (and remote?).

Just linux currently.  remote's in the queue.

-- 
Pedro Alves

Re: [non-stop] 00/10 non-stop mode

[Nick Roberts]

 > Selecting non-stop or all-stop modes, is something the user will
 > want to do (even if all-stop mode gets to be implemented on top of
 > non-stop in the future), as both modes are useful.

If non-stop is available, under what circumstance would someone choose to
use all-stop?

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

Re: [non-stop] 00/10 non-stop mode

[Pedro Alves]

A Thursday 19 June 2008 05:38:00, Nick Roberts wrote:
> If non-stop is available, under what circumstance would someone choose to
> use all-stop?

When someone wants all-stop behaviour.

-- 
Pedro Alves

RE: [non-stop] 00/10 non-stop mode

[Marc Khouzam]

> > If non-stop is available, under what circumstance would someone choose to
> > use all-stop?
>
> When someone wants all-stop behaviour.

:-)
When we first discussed non-stop debugging, I also thought that once
it was available, there would be no reason for all-stop.
However, after talking to different people, it seems that it can
come down to a matter of taste and that some users prefer all-stop.

Also, from what I understand, non-stop was a necessary step to get
to multi-process. Some of the users I've spoken to didn't actually mind
all-stop within a single process (for threads), as long as multi-process 
was non-stop.

All this to say that it does seem that all-stop may still be chosen by some.

Marc

Re: [non-stop] 00/10 non-stop mode

[Daniel Jacobowitz]

On Thu, Jun 19, 2008 at 04:38:00PM +1200, Nick Roberts wrote:
>  > Selecting non-stop or all-stop modes, is something the user will
>  > want to do (even if all-stop mode gets to be implemented on top of
>  > non-stop in the future), as both modes are useful.
> 
> If non-stop is available, under what circumstance would someone choose to
> use all-stop?

For non-time-sensitive applications, all-stop is probably more
intuitive - a lot easier to explain to users, especially users of the
command line.

-- 
Daniel Jacobowitz
CodeSourcery