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

[Nick Roberts <nickrob@snap.net.nz>]

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