Community
Participate
Working Groups
With the upcoming improved GDB debug console, it will become more important that the Debug View selection be kept in sync with the state of the GDB used as back-end, and vice versa. This will make the workflow better, for users who want to use both the CDT UI and the console, in a complementary way, for debugging.
New Gerrit change created: https://git.eclipse.org/r/79336
New Gerrit change created: https://git.eclipse.org/r/79337
New Gerrit change created: https://git.eclipse.org/r/79339
New Gerrit change created: https://git.eclipse.org/r/84099
New Gerrit change created: https://git.eclipse.org/r/84775
Gerrit change https://git.eclipse.org/r/77896 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=dc6e3a06ff3734457340c62558863c34a0500440
Gerrit change https://git.eclipse.org/r/84775 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=e8480ca0f8c72f1eb1a7d31f6c48789eef1bf9ba
To support the full GDB console, we need to use mi-async (used to be called 'target-async') with all-stop mode. With mi-async, CDT is able to and does send commands to GDB when the inferior is running. The patch is under review now at https://git.eclipse.org/r/#/c/84382/ With mi-async, when testing an automatic remote session with all-stop, Alvaro and I tried leaving the inferior running. In that case, the thread node was still being shown and when selecting it, we noticed that gdb was rejecting the -thread-select command. This does not happen with non-stop. To reproduce: 1- apply the review mentioned above (unless it has been committed already) 2- launch an automatic debug session with GDB 7.12 and all-stop 3- resume the program from CDT and let it continue to run 4- select the thread We saw the following error: 936,592 [MI] 55-thread-select 1 936,593 [MI] &"Cannot execute this command while the target is running.\n" 936,593 [MI] &"Use the \"interrupt\" command to stop the target\n" 936,593 [MI] &"and then try again.\n" 936,593 [MI] 55^error,msg="Cannot execute this command while the target is running.\nUse the \"inte\ rrupt\" command to stop the target\nand then try again." 936,594 [MI] (gdb) !ENTRY org.eclipse.cdt.dsf 4 10005 2016-11-14 17:02:16.594 !MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.gdb.internal.ui.sync.GdbDebugContextSyncManager$1$1@541a390b): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Failed to execute MI command: -thread-select 1 Error message from debugger back end: Cannot execute this command while the target is running.\nUse the "interrupt" command to stop the target\nand then try again. java.lang.Exception: Cannot execute this command while the target is running.\nUse the "interrupt" command to stop the target\nand then try again.' resulted in an error. !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2016-11-14 17:02:16.594 !MESSAGE Failed to execute MI command: -thread-select 1 Error message from debugger back end: Cannot execute this command while the target is running.\nUse the "interrupt" command to stop the target\nand then try again. !STACK 0 java.lang.Exception: Cannot execute this command while the target is running.\nUse the "interrupt" command to stop the target\nand then try again. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:941) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:770)
(In reply to Marc Khouzam from comment #8) > With mi-async, when testing an automatic remote session with all-stop, > Alvaro and I tried leaving the inferior running. In that case, the thread > node was still being shown and when selecting it, we noticed that gdb was > rejecting the -thread-select command. I am able to reproduce this. But I wonder if it's really an issue. In all-stop, while the target is running, it's not permitted to switch thread. So the same thing happens if the user tries to change thread from the console. One thing that would make the synchronization work better in all-stop is if the thread selected, when suspending execution, would be the one that ends-up selected, once the suspend has happened. Here are the traces of the suspend; we can see that we do specify the selected thread (3 in this case). 879,657 116-exec-interrupt --thread 3 879,657 116^done 879,658 (gdb) 879,658 ~"\nThread " 879,658 ~"1 \"multipleThreads\" received signal SIGINT, Interrupt.\n" 879,660 ~"0x00007ffff75b3dfd in nanosleep () from target:/lib/x86_64-linux-gnu/libc.so.6\n" 879,660 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={add\ r="0x00007ffff75b3dfd",func="nanosleep",args=[],from="target:/lib/x86_64-linux-gnu/libc.so.6"},threa\ d-id="1",stopped-threads="all",core="3" However, the GDB stopped notification we get says that the thread id is "1", so we end-up selecting that one.
(In reply to Marc Dumais from comment #9) > (In reply to Marc Khouzam from comment #8) > > With mi-async, when testing an automatic remote session with all-stop, > > Alvaro and I tried leaving the inferior running. In that case, the thread > > node was still being shown and when selecting it, we noticed that gdb was > > rejecting the -thread-select command. > > I am able to reproduce this. But I wonder if it's really an issue. In > all-stop, while the target is running, it's not permitted to switch thread. > So the same thing happens if the user tries to change thread from the > console. Right. Can we simply silence the errors by not sending the command in that case? > One thing that would make the synchronization work better in all-stop is if > the thread selected, when suspending execution, would be the one that > ends-up selected, once the suspend has happened. Here are the traces of the > suspend; we can see that we do specify the selected thread (3 in this case). > > 879,657 116-exec-interrupt --thread 3 > 879,657 116^done > 879,658 (gdb) > 879,658 ~"\nThread " > 879,658 ~"1 \"multipleThreads\" received signal SIGINT, Interrupt.\n" > 879,660 ~"0x00007ffff75b3dfd in nanosleep () from > target:/lib/x86_64-linux-gnu/libc.so.6\n" > 879,660 > *stopped,reason="signal-received",signal-name="SIGINT",signal- > meaning="Interrupt",frame={add\ > r="0x00007ffff75b3dfd",func="nanosleep",args=[],from="target:/lib/x86_64- > linux-gnu/libc.so.6"},threa\ > d-id="1",stopped-threads="all",core="3" > > However, the GDB stopped notification we get says that the thread id is "1", > so we end-up selecting that one. Yes, I noticed that too. When hitting a breakpoint it works as expected, meaning that if thread 3 hits a breakpoint, the *stopped event shows thread 3 and we select it. But for interrupt, it is always thread 1. This would be an enhancement for GDB though.
