Re: [rfc] Fix qC handling in gdbserver

Daniel Jacobowitz
2007-04-27T11:27:35Z

On Fri, Apr 27, 2007 at 10:01:12AM +0200, Markus Deuling wrote:
> When looking at gdb.base/info-proc.exp I found a bug in remote target.
>
> GDB tries to get the initial pid after "target remote :<port>". It does
> that by set_thread (-1, 0), which results in a "Hc-1" packet. On gdbserver side
> each Hc packet with '0' or '1' results in E01 packet as reply.

Consider the comment you're deleting. There are remote stubs out
there that work with versions of GDB older than thread support - I
don't know if any of them are still in use, but I have no way to
check, either. They will report thread information if they think GDB
supports it, but not otherwise. I think the remote.c change is wrong.

> Later on remote_current_thread (inferior_ptid); is called which always comes
> back with MAGIC_NULL_PID. The reason for that is the missing support for 'qC'
> packets in gdbserver. Manual says the reply for qC
> is 'QC pid'. If no pid returns MAGIC_NULL_PID is taken.

You should have read the paragraph just above :-)

Like the descriptions of the other packets, each description here
has a template showing the packet's overall syntax, followed by an
explanation of the packet's meaning. We include spaces in some of the
templates for clarity; these are not part of the packet's syntax. No
GDB packet uses spaces to separate its components.

So the reply doesn't have a space in it. But there's a bigger problem
here. Look at this:

> Because of that 'info proc' is broken directly after connecting to
> gdbserver (it tries to access /proc/42000), thats why the testcase failes.

GDB is opening /proc/pid on the _local_ machine. That's silly.
gdbserver is usually running on a remote machine; it's only on the
local machine during native testing. The testcase fails because info
proc only works for native targets.

We could fix this, since I was just discussing with Pedro some gdb
protocol extensions for opening remote files...

--
Daniel Jacobowitz
CodeSourcery