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

Pedro Alves
2008-06-18T13:40:38Z

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