Re: Q: %Stop && gdb crash

[Oleg Nesterov <oleg@redhat.com>]

Forgot to mention,

On 08/03, Oleg Nesterov wrote:
>
> So I assumed it is always safe to resend the notification unless gdb already
> sent vStopped. Since it is not clear to me when it makes sense to resend it,
> currently gdbstub does re-send every time /proc/ugdb reports the new event
> (T00 in this case). I agree this is not optimal, but this looks correct to me.

I'll change gdbstub to never resend the notification to avoid the problem.
But probably gdb should be fixed anyway.

And, now I recalled why I added resend into the initial code. This is
because I hit another minor problem which I misinterpreted as if gdb
can miss the notification.

To avoid the unnecessary details, consider the oversimplified example,

	$ sleep 10000&
	[1] 2923

	$ cat > SLEEP
	set target-async on
	set non-stop
	target extended-remote :2000
	file /bin/sleep
	attach 2923
	info registers
	detach
	^D

	$ gdb <SLEEP
	GNU gdb (GDB) 7.1
	Copyright (C) 2010 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
	and "show warranty" for details.
	This GDB was configured as "x86_64-unknown-linux-gnu".
	For bug reporting instructions, please see:
	<http://www.gnu.org/software/gdb/bugs/>.
	(gdb) (gdb) (gdb) Remote debugging using :2000
	(gdb) Reading symbols from /bin/sleep...(no debugging symbols found)...done.
	(gdb) Attached to process 2923
	[New Thread 2923.2923]
	Target is executing.
	(gdb) Detached from remote process 2923.
	(gdb) quit

And yes, gdb ignores %Stop and just detaches. But this is because
of another issue (which looks like a minor gdb bug to me), note the

	"Target is executing."

above. This is the reply to "info registers". Why? OK, yes, it is
executing. Then send vCont:t ? "attach PID" means attach and stop
it, no? And note, the same commands work as expected in CLI mode.

I also tried to add "interrupt" before "info registers", this doesn't
help although in this case gdb does send vStopped.


Can't resist, I spent a lot of time trying to understand what is
wrong. Because at first I played with the real gdbserver via CLI
to ensure everything works as I expect, then I tried to achieve the
same results with /proc/ugdb doing "$ gdb < BATCH_FILE" with the
same commands.

Oleg.