On 08/20/2015 04:51 PM, Pedro Alves wrote:
I don't see a quick, easy and good way around waiting for the whole file to read.
Having GDB handle ctrl-c differently while it is handling internal events
is already a source of trouble, and the fix always seemed to me to be to make ctrl-c
work like what is happening here. Specifically, I mean that e.g., say that the
user sets a conditional breakpoint that is evaluated on gdb's side, and then the
target stops for that conditional breakpoint, gdb evaluates the expression,
and then resumes the target again, on and on. If the user presses ctrl-c just
while the conditional breakpoint's expression is being evaluated, and something along
that code path called target_terminal_ours (thus pulling input/ctrl-c to the
regular "Quit" SIGINT handler), gdb behaves differently (shows a "Quit" and the
debug session ends up likely broken) from when the ctrl-c is pressed while the target
is really running. I'd argue that the ctrl-c in both cases should be passed
down all the way to the target the same way, and that any internal stop and
breakpoint condition evaluation is magic that should be hidden. Just like
what is happening here with file reading.
Though having said that, it does look like even that isn't working properly,
as I'd expect this:
(top-gdb) c
Continuing.
(no debugging symbols found)...done.
Breakpoint 1, main (argc=1, argv=0x7fffffffe3d8) at ../../../src/gdb/gdbserver/server.c:3635
3635 ../../../src/gdb/gdbserver/server.c: No such file or directory.
(gdb)
to be slow (that is, the file reading isn't really interrupted), but then
the target stops with SIGINT as soon as gdb resumes it again after reading
the DSOs. But it is reaching main anyway, and there's no sign
of "Program stopped with SIGINT"...
Not sure where the bug is. It may be on the gdbserver side.
OK, so gdbserver receives the \003, but since the target is stopped,
the normal packet processing loop discards the \003, as it doesn't
look like a start of a RSP packet frame (that is, it isn't a $).
I'm thinking that maybe the best way to handle this may be to still
leave SIGINT forwarding to the target, so that in case gdb re-resumes
the target quick enough, the ctrl-c turns into a real SIGINT on the
target. But then if it takes long for gdb or gdbserver or the target
to react to the ctrl-c, then the user presses ctrl-c again, and gdb
shows the old:
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n)
AFAICS, that query is never issued anywhere if the target
is async. And the remote target is always async nowadays.
To make that query appear promptly, we'd hook it to the
QUIT macro. Something like this:
(gdb) c
Continuing.
Reading symbols from target:/lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
^CInterrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
Quit
(gdb)
Could you try the hacky patch below just to see if it makes a
difference to you? It seems that GDB still doesn't react
as soon as it could, but I'd guess that Gary's previous patch
to add a QUIT around vFile:pread's would fix that.