doryan/BloomPatched
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Corrected bug in GDB InterruptExecution command handler, where a failure to interrupt target execution wasn't clearing the DebugSession::waitingForBreak flag

Browse Source
This commit is contained in:
Nav
2022-04-16 21:22:48 +01:00
parent b05b3454e9
commit fe665cb763
1 changed files with 10 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/DebugServer/Gdb/CommandPackets/InterruptExecution.cpp
View File

@@ -21,11 +21,20 @@ namespace Bloom::DebugServer::Gdb::CommandPackets
try { try {
targetControllerConsole.stopTargetExecution(); targetControllerConsole.stopTargetExecution();
debugSession.connection.writePacket(TargetStopped(Signal::INTERRUPTED)); debugSession.connection.writePacket(TargetStopped(Signal::INTERRUPTED));
debugSession.waitingForBreak = false;
} catch (const Exception& exception) { } catch (const Exception& exception) {
Logger::error("Failed to interrupt execution - " + exception.getMessage()); Logger::error("Failed to interrupt execution - " + exception.getMessage());
debugSession.connection.writePacket(ErrorResponsePacket()); debugSession.connection.writePacket(ErrorResponsePacket());
} }
/*
* Whenever we respond to an interrupt signal, GDB always assumes that target execution has stopped. Even if we
* respond with an error packet.
*
* Because of this, we always set the DebugSession::waitingForBreak flag to false, even if we failed to
* interrupt target execution. This way, we won't end up sending an unexpected stop reply packet to GDB, when
* the target does eventually stop (for some other reason).
*/
debugSession.waitingForBreak = false;
} }
} }