On 10/1/18 6:39 PM, Philippe Mathieu-Daudé wrote:
> Hi Luc,
>
> On 01/10/2018 13:56, Luc Michel wrote:
>> Add support for the '!' extended mode packet. This is required for the
>> multiprocess extension.
>>
>> Signed-off-by: Luc Michel <luc.mic...@greensocs.com>
>> ---
>> gdbstub.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/gdbstub.c b/gdbstub.c
>> index 299783b3b8..d372972dd3 100644
>> --- a/gdbstub.c
>> +++ b/gdbstub.c
>> @@ -1280,10 +1280,13 @@ static int gdb_handle_packet(GDBState *s, const char
>> *line_buf)
>> trace_gdbstub_io_command(line_buf);
>>
>> p = line_buf;
>> ch = *p++;
>> switch(ch) {
>> + case '!':
>> + put_packet(s, "OK");
>
> Don't we want to also support the 'R' packet?
Hi Philippe,
Thank you for all you reviews!
I'm not sure about this one:
- do you think calling qemu_system_reset() is the right thing to do?
- what should we do in user mode? Is there a way to restart the
emulated binary?
- Looking at the GDB sources, GDB seems to send an 'R' packet on the
"run" command. It starts by a "vKill;pid" packet, then a "vRun". If
"vRun" is not supported by the remote, it falls back to "R". So it seems
that if we want to support "run", we must also implement "vKill;pid",
which probably doesn't make much sense for QEMU. One possible
implementation that would probably work for system mode would be to:
- do nothing on 'vKill;pid' packet
- do not implement the 'vRun' packet
- call qemu_system_reset() on 'R' packet
But it does not align well with the current 'k' packet behaviour, which
simply do an exit(0). Do you have an opinion on this?
Thanks.
Luc.
>
>> + break;
>> case '?':
>> /* TODO: Make this return the correct value for user-mode. */
>> snprintf(buf, sizeof(buf), "T%02xthread:%s;", GDB_SIGNAL_TRAP,
>> gdb_fmt_thread_id(s, s->c_cpu, thread_id,
>> sizeof(thread_id)));
>> put_packet(s, buf);
>>
