Open Alsoprach opened 1 year ago
elicn
commented
1 year ago The last incoming command is vCont;S0f:pa410.1996;c:pa410.-1.
Since vCont support is limited, Qiling doesn't know how to handle the S0f command and fails.
We should fix that.
Alsoprach
commented
1 year ago Thank you for your reply
bstee615
commented
1 year ago I'm also experiencing this issue. Is there any fix or workaround for it? Would running on a compatible VM or using a different debugger solve the issue, and if so, what do you suggest to try?
Here is the last bit of my log - seems to break on the same command:
[=] gdb> breakpoint added at 0x7ffff7de5590
[+] putpkt ("OK");
[+] getpkt ("QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;");
[+] putpkt ("OK");
[+] getpkt ("vCont;S0f:pa410.1996;c:pa410.-1");
[+] putpkt ("");
GreaterGoodest
commented
6 months ago Same issue here, usually if I try to do anything (step, continue, etc) after hitting a breakpoint I get a SIGTERM disconnect.
cbdm
commented
1 month ago I was also getting this issue. I think I found the issue and a possible workaround.
The issue seems that the handle_s method inside the gdb server sends a sigterm if Qiling has stopped the emulation: https://github.com/qilingframework/qiling/blob/9a78d186c97d6ff42d7df31155dda2cd9e1a7fe3/qiling/debugger/gdb/gdb.py#L683-L684
Following the calls from self.gdb.resume_emu(steps=1) above that check, we get to Qiling.emu_start, and in that method it also sets emulation as stopped once it has executed the number of steps: https://github.com/qilingframework/qiling/blob/9a78d186c97d6ff42d7df31155dda2cd9e1a7fe3/qiling/core.py#L766-L771
So qiling doesn't seem to know whether the emulation stopped because the program exited or if the emulation stopped because we're simply debugging.
Commenting out that if-statement. Really.
You need to find where qiling is installed (python -c "from qiling import __file__; from os.path import dirname; print(dirname(__file__))").
In my case, running inside docker, I get this: /usr/local/lib/python3.12/site-packages/qiling
Then edit /usr/local/lib/python3.12/site-packages/qiling/debugger/gdb/gdb.py and comment out lines 683 and 684.
So far it's been ok, only issue is that the gdb-client doesn't know when the process terminates, so you might get a bad exit if you step too much.
*Describe the bug When qiling runs the x8664_linux program and enables default GDB remote debugging, two n/si instructions issued by GDB will trigger warning: Invalid remote reply, causing debugging to fail. But the breakpoint-based c instruction is normal.
Sample Code
Expected behavior Remote gdb can debug normally without restriction.
Screenshots
Additional context Part of the log.