qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] gdb run / pause broken for some debuggers


From: Lucien Anti-Spam
Subject: [Qemu-devel] gdb run / pause broken for some debuggers
Date: Thu, 24 Jan 2019 14:25:41 +0000 (UTC)

Hi gdbstub maintainers (CC: Luc Michel as he wrote the patch that probably 
caused this issue)
I have found an issue with IDA Pro when moving to QEMU3.x where RUN/PAUSE has 
stopped working.
I am pretty sure its to do with this debugger sending no thread-id with the 
vCont packet action
That is that IDA Pro sends "vCont;c" (action=c, thread-id=none).  
This is defined in the RSP document as "An action with no thread-id matches all 
threads."
(https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html#vCont-packet )
In commit e40e5204af8388e605df2325d9b562c05919350e, which added multiprocess 
support for vCont packets, the new code errors right away if it finds no ":" 
action\thread-id separator as shown below:
 if (*p++ != ':') {     res = -ENOTSUP;...
The upper function calling gdb_handle_vcont when -EINVAL or -ERANGE will spit 
out an "E22" error message, but for -ENOTSUP  we do goto-unknown_command label 
results in IDA Pro thinking the gdbstub is dead.
            res = gdb_handle_vcont(s, p);            if (res) {                
if ((res == -EINVAL) || (res == -ERANGE)) {                    put_packet(s, 
"E22");                ... else goto unknown_command:
Maybe we should extend this to add a "-ENOTSUP" clause so the "E22" is also 
returned?
This "unknown_command:" branch should probably send a "E nn" packet rather than 
just a blank "+" ack although here I do admit the spec is very unclear but in 
most cases they do spec out "E nn" when some part of the command turns to 
garbage. 
...        unknown_command:            /* put empty packet */           buf[0] 
= '\0';           put_packet(s, buf);


If people more experienced in this agree I will go ahead and try at a patch for 
both of these issues.
Cheers,Luc


reply via email to

[Prev in Thread] Current Thread [Next in Thread]