Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse
  • From: Adrian Oltean <adrian.oltean@xxxxxxx>
  • Date: Mon, 27 Apr 2020 15:58:34 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kX9iIala927XZ6fkhVPMtXCVQZam7k265Px3H6RUoc0=; b=lAvHC+8E/QO6qTE8paeUxJKU0c2LnPIf0jFV857f9u0mfozuQd3zYFeVvSutW/sWFOyKZ483NPMwagSwgEeGezub5p0qLxBVXfuQLixcIIL0pEsgf+DuB2Vi7zmicARLdI2R3OEJFCfRhE7NbLNnvcGhR1gG7+p9NJq3x7tE4kGTf+NmxETQzvfIcuaPCG2Rl3Hki5Jo4zIMkaDHN6Dj4zKcCIMy728Si25vm1NqiADbLgKlgkShRdth6VW5nnIN14kiJDk9p/QxBMsHnzqU3NmLBrlK0kGeHEeCaHjvldllLBU8iJdxIXHJZyKF9xpTKPmzJGi0mXEZT7SJQNmrVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=CNOJLBiEItjAJHEkrp3MGIMbX8fJQwcNzEYRS7/R7RC/ozVXnc+FXc5eXCNIELGZHazGy8Ol6zy2D3QHQdG/oGqYX1Hs5Z46CbnhniopR90GK1q8yyLJiIuSJKYS44iEB2T+LDwY4nDiGIvDgWSQA9T2E0KAP+j8zL2m70R4avyYhvSKsTh8/1fIGxnKzTP1B1efMYbAzDob9uYRH1/o1ADfd88fL0Tss7BlyJGGEgh0JWVT+Eihi/OtZcw7JvvGSQbg3NjorJRfOBNJ66+c1qBPg60iIRED68lrEUO6Nc8Rexxa7BGHF/ApIqdvPr4iiJyw/UNM+gSFya8CY/4fbA==
  • Delivered-to: cdt-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: AdYcrCX1qzmO713PSuSEuG6cq5vUpA==
  • Thread-topic: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse

Hi Jonah,


Thanks a lot for the follow-up on the GDB mailing list. I hope Pedro clarifies current behavior of GDB.


Meanwhile, I’ve been working on a workaround in CDT. Not sure if this is what you had in mind, so briefly, here’s what I did in my environment:

  1. Write an MIQuitEvent class extending MIEvent
  2. Implement an extension of MIRunControlEventProcessor_7_12 and make sure to return an instance of this via GDBControl_7_12’s createMIRunControlEventProcessor()
  3. In the newly implemented event processor, inspect the OOB records and specifically look for “Quit” – this is being printed when Ctrl-C is passed but GDB is in async mode
  4. Once “Quit” is identified, dispatch a new MIQuitEvent on the DSF session
  5. Extend GDBRunControl_7_12 and make sure to return this via GdbDebugServicesFactory’s createRunControlService()
  6. Inside the extended GDBRunControl_7_12 service, add an eventDispatched(MIQuitEvent) method and make sure to also queue an ‘-exec-interrupt’ command (basically, what’s being done when isFullGdbConsoleSupported() is true).


Any thoughts on the approach I described? I also tried sending an ‘-exec-interrupt’ along with any Ctrl-C but this breaks the debug session – a subsequent ‘continue’ ends-up triggering an ‘The target is not responding to interrupt requests’ error.





From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Saturday, April 25, 2020 9:42 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse


Caution: EXT Email

Hi Adrian,


I replied to the underlying GDB issue on gdb's mailing list. For the GDB issue we can discuss there. After bisecting the code I found the specific commit, but more importantly I found a much reduced test case that causes CDT to "misbehave" when a user runs a command in the background and affects any target not already in async mode. i.e. if a user runs "continue&" in the CLI, then CDT will not be able to interrupt it if CDT thinks GDB is in sync mode. The only way to interrupt it is to type "interrupt" in the CLI and then proceed as normal. 


Therefore a fix for this could be that CDT attempts to interrupt the target with Ctrl-C and sending "interrupt" on the MI channel, even when using sync mode. Your case would also be fixed by this. 


For your immediate use case, simply sending "interrupt" instead of Ctrl-C may solve or workaround your GDB problem.


Please let me know what you think and if you want to proceed with this please raise a bug and I can help guide you on a fix for this.






Jonah Graham
Kichwa Coders



On Fri, 24 Apr 2020 at 16:26, Adrian Oltean wrote:

Thank you, Jonah. I’ll ping the GDB mailing list.  To be honest, I hoped for an oversight on the CDT side (easier to fix in my environment)

but with everything that I gathered so far plus having your inputs, it leads to a GDB issue. And I’m 99% that it’s related to the things

implemented for supporting the ‘enhanced’ console. Do you happen to know the contact person from GDB side that worked on



As a side note, back in January, I’ve been trying to identify inside GDB, what’s causing the behavior I described. As an ‘outsider’, understanding

some of the GDB’s internals is really complicated, so I gave up at that point…


If no one from GDB can shed some light on this, I’m tempted to work around the problem inside CDT and inside the python scripts I

have.  If I’ll find a workaround, of course. At this point, identifying the problem inside GDB is a no go for me.


Thanks again,



From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Friday, April 24, 2020 9:48 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse


Caution: EXT Email

Hi Adrian,


Your GDB message does explain this problem fully. As you didn't get an answer, I recommend pinging that mailing list to see if it sparks a reply.



CDT could look into working around any issue in GDB - but that will be easier once the GDB issue is understood.







Jonah Graham
Kichwa Coders



On Fri, 24 Apr 2020 at 12:55, Adrian Oltean wrote:

You’re right – regardless of GDB version, async mode is off by default on Windows.


However, as far as I can tell from my experiments, that ‘continue’ executed via gdb.post_event() puts GDB somehow in the

async mode. So, even though it was accepting CTRL+C at the beginning of the debug session, it’ll end-up asking for

an ‘-exec-interrupt’ once ‘continue’ gets executed via gdb.post_event().


By the way, I’ve just remembered about this - Maybe it helps.





From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Friday, April 24, 2020 7:27 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse


Caution: EXT Email

Hi Adrian,


That is strange indeed. It sounds like no interrupt will work under any circumstances on Windows in that case? - i.e. it isn't reliant on the Pyhon script. IIRC on Windows we don't use async, so Ctrl-C is still the correct thing to do. I'll boot up a Windows computer and see if I can reproduce it.




Jonah Graham
Kichwa Coders



On Fri, 24 Apr 2020 at 11:35, Adrian Oltean wrote:

Hi Jonah,


Thanks for the hint. While inserting a delay seems to improve the situation on my basic Linux setup,

it doesn’t seem to work in my other (more complex) use case. So, with this in mind, I think it’s safe

to say that we’re dealing with a timing issue on Linux.


However, on Windows, there’s a more fundamental issue. This doesn’t look like a timing issue at

all. Basically, CDT issues an interrupt via CTRL+C instead of executing an ‘-exec-interrupt’. That’s

because I’m seeing a “Quit” message in the Debugger Console when trying to suspend app after

the execution of ‘continue’ via gdb.post_event().


Any other pointers that could help in making my use case functional?





From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Thursday, April 23, 2020 10:18 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse


Caution: EXT Email

Hi Adrian,


Thanks for the MI trace. It looks to me like the *running may not be getting processed in time, leaving CDT in a bad state. So to answer your question, I recommend confirming this hypothesis by trying a short delay before issuing continue. The trace shows it currently at 4 ms after *stopped. If that fixes it, then you can trace the events in DSF to find out which events are causing the issue. I can provide more pointers on tracing DSF events if you need that later. 





On Thu., Apr. 23, 2020, 14:59 Adrian Oltean wrote:

Hi Jonah,


Sure, I’ll leave the GDB traces for Windows and Linux below. But please keep in mind that reproducing the problem is fairly easy and there’s no need for any complicated setups. Ignore my complicated setup from Windows. :-)





------------------ GDB traces – Windows host ------------------

174,573 (gdb)

176,138 3-gdb-version

176,145 ~"GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major)\n"

176,145 ~"Copyright (C) 2019 Free Software Foundation, Inc.\n"

176,145 ~"License GPLv3+: GNU GPL version 3 or later <>\nThis is fre\

e software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitt\

ed by law."

176,145 ~"\nType \"show copying\" and \"show warranty\" for details.\n"

176,145 ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n"

176,145 ~"Type \"show configuration\" for configuration details.\n"

176,145 ~"For bug reporting instructions, please see:\n"

176,145 ~"<>.\n"

176,145 ~"Find the GDB manual and other documentation resources online at:\n    <\


176,145 ~"\n\n"

176,146 ~"For help, type \"help\".\n"

176,146 ~"Type \"apropos word\" to search for commands related to \"word\".\n"

176,146 3^done

176,146 (gdb)

176,147 4-environment-cd xxx/frdmk\


176,158 4^done

176,158 (gdb)

176,159 5-gdb-set breakpoint pending on

176,170 5^done

176,170 (gdb)

176,171 6-gdb-set detach-on-fork on

176,180 6^done

176,180 (gdb)

176,181 7-enable-pretty-printing

176,191 7^done

176,191 (gdb)

176,192 8-gdb-set python print-stack none

176,201 8^done

176,201 (gdb)

176,202 9-gdb-set print object on

176,212 9^done

176,212 (gdb)

176,213 10-gdb-set print sevenbit-strings on

176,222 10^done

176,222 (gdb)

176,222 11-gdb-set host-charset UTF-8

176,233 11^done

176,233 (gdb)

176,234 12-gdb-set target-charset WINDOWS-1252

176,243 12^done

176,243 (gdb)

176,244 13-gdb-set target-wide-charset UTF-16

176,254 13^done

176,254 (gdb)

176,254 14-gdb-set dprintf-style call

176,264 14^done

176,264 (gdb)

176,265 15-gdb-set target-async off

176,274 15^done

176,274 (gdb)

176,275 16-gdb-set record full stop-at-limit off

176,284 16^done

176,284 (gdb)

176,285 17-gdb-set auto-solib-add on

176,294 17^done

176,294 (gdb)

176,299 18-file-exec-and-symbols --thread-group i1 xxx/frdmkw36_demo_apps_bubble/Debug/frdmkw36_demo_apps_bubble.axf

176,317 18^done

176,317 (gdb)

176,318 19-interpreter-exec console "set remotetimeout 60000"

176,327 =cmd-param-changed,param="remotetimeout",value="60000"

176,327 19^done

176,327 (gdb)

176,334 20-target-select extended-remote | xxx_custom_stub_invoked_xxx

177,765 =thread-group-started,id="i1",pid="42000"

177,766 =thread-created,id="1",group-id="i1"

177,827 ~"ResetISR () at ../startup/startup_mkw36z4.c:288\n"

177,827 ~"288\tvoid ResetISR(void) {\n"

177,827 *stopped,frame={addr="0x00000124",func="ResetISR",args=[],file="../startup/startup_mkw36z4.c\




177,844 20^connected

177,844 (gdb)

177,845 21-interpreter-exec console "set mem inaccessible-by-default off"

177,854 =cmd-param-changed,param="mem inaccessible-by-default",value="off"

177,854 21^done

177,854 (gdb)

177,855 22-interpreter-exec console "mon ondisconnect cont"

177,876 22^done

177,876 (gdb)

177,877 23-interpreter-exec console "set arm force-mode thumb"

177,886 =cmd-param-changed,param="arm force-mode",value="thumb"

177,886 23^done

177,886 (gdb)

177,887 24-interpreter-exec console "set remote hardware-breakpoint-limit 4"

177,897 =cmd-param-changed,param="remote hardware-breakpoint-limit",value="4"

177,897 24^done

177,897 (gdb)

177,898 25set range-stepping on

177,907 &"set range-stepping on\n"

177,918 25^done

177,918 (gdb)

177,919 26-interpreter-exec console "mon semihost enable"

177,939 26^done

177,940 (gdb)

177,940 27-target-download

177,951 27+download,{section=".text",section-size="28328",total-size="180010"}

177,951 27+download,{section=".text",section-sent="16000",section-size="28328",total-sent="16000",to\


177,952 27+download,{section=".data",section-size="112",total-size="180010"}

178,415 28-list-thread-groups

178,554 27^done,address="0x124",load-size="28440",transfer-rate="397760",write-rate="9480"

178,554 (gdb)

178,555 29-interpreter-exec console "mon SWO datasource"

178,556 28^done,groups=[{id="i1",type="process",pid="42000",executable="xxx\\frdmkw36_demo_apps_bubble\\Debug\\frdmkw36_demo_apps_\


178,556 (gdb)

178,563 30-list-thread-groups i1

178,567 29^done

178,567 (gdb)

178,580 30^done,threads=[{id="1",target-id="Thread 1",details="Runnable",frame={level="0",addr="0x00\



178,580 (gdb)

178,587 31-gdb-show --thread-group i1 language

178,588 32-stack-info-depth --thread 1 11

178,591 31^done,value="auto"

178,591 (gdb)

178,592 32^done,depth="1"

178,592 (gdb)

178,592 33-gdb-set --thread-group i1 language c

178,603 33^done

178,603 (gdb)

178,604 34-interpreter-exec --thread-group i1 console "p/x (char)-1"

178,614 ~"$1 = 0xff\n"

178,614 34^done

178,614 (gdb)

178,615 35-data-evaluate-_expression_ --thread-group i1 "sizeof (void*)"

178,624 35^done,value="4"

178,625 (gdb)

178,625 36-gdb-set --thread-group i1 language auto

178,636 36^done

178,636 (gdb)

178,636 37-interpreter-exec --thread-group i1 console "show endian"

178,646 ~"The target endianness is set automatically (currently little endian)\n"

178,646 37^done

178,646 (gdb)

178,768 38-break-insert -t -h -f main

178,796 38^done,bkpt={number="1",type="hw breakpoint",disp="del",enabled="y",addr="0x000007c2",func=\



178,796 (gdb)

178,802 39-exec-continue --thread-group i1

178,806 39^running

178,806 *running,thread-id="all"

178,807 (gdb)

178,915 =breakpoint-modified,bkpt={number="1",type="hw breakpoint",disp="del",enabled="y",addr="0x00\



178,937 ~"\n"

178,937 ~"Temporary breakpoint 1, main () at ../source/bubble.c:163\n"

178,938 ~"163\t    uint8_t sensorRange = 0;\n"

178,938 *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000007c2",func="main",\



178,938 =breakpoint-deleted,id="1"

178,938 (gdb)

180,464 40-stack-select-frame --thread 1 0

180,470 40^done

180,470 (gdb)

180,482 41-stack-info-depth --thread 1 2

180,492 41^done,depth="1"

180,492 (gdb)

181,336 42-data-list-register-names --thread-group i1

181,346 42^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12",\




181,347 (gdb)

181,349 43-data-list-register-values --thread 1 --frame 0 x 25

181,389 43^done,register-values=[{number="25",value="0x61000000"}]

181,389 (gdb)

181,591 44-thread-info 1

181,599 44^done,threads=[{id="1",target-id="Thread 1",details=" ",frame={level="0",addr="0x000007c2"\



181,600 (gdb)

182,965 45-stack-select-frame --thread 1 0

182,975 45^done

182,975 (gdb)

183,156 46-stack-select-frame --thread 1 0

183,163 46^done

183,163 (gdb)


//***** Executing the python script using Debugger Console  *****//

191,292 47-interpreter-exec console "source"

191,297 47^done

191,298 (gdb)


//***** Resuming from Eclipse. Target app now stopped in 'main'. *****//

202,900 48-exec-continue --thread 1

202,908 48^running

202,908 *running,thread-id="all"

202,908 (gdb)

202,956 49-thread-select 1


//***** Suspending from Eclipse. 'continue' gets executed from the script and Eclipse shows app as running (expected) *****//

212,656 ~"\nProgram"

212,657 ~" received signal SIGINT, Interrupt.\n"

212,707 ~"0x00001d9c in I2C_MasterTransferBlocking (base=0x40066000, xfer=0x2000bfbc) at ../drivers/\


212,707 ~"964\t            while (!(base->S & kI2C_IntPendingFlag))\n"

212,707 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={add\




212,707 (gdb)

212,708 ~"Executing <continue>\n"

212,708 *running,thread-id="all"

212,710 50-data-list-register-values --thread 1 --frame 0 x 25

212,719 49^error,msg="Cannot execute this command while the target is running.\nUse the \"interrupt\\

" command to stop the target\nand then try again."

212,720 (gdb)

212,720 50^error,msg="Selected thread is running."

212,720 (gdb)



//***** Suspend again. Now we should see target really suspended. However, 'interrupt failed' error is shown. *****//

222,474 &"Quit\n"

222,975 51-interpreter-exec --thread-group i1 console kill

222,975 &"Quit\n"

222,976 ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n"

222,976 &"Cannot execute this command while the target is running.\n"

222,976 &"Use the \"interrupt\" command to stop the target\n"

222,976 &"and then try again.\n"

222,976 51^error,msg="Cannot execute this command while the target is running.\nUse the \"interrupt\\

" command to stop the target\nand then try again."

222,976 (gdb)


//***** Terminate executed. Error is shown. Debug session not terminated. *****//

236,776 52-thread-select 1

236,777 52^error,msg="Cannot execute this command while the target is running.\nUse the \"interrupt\\

" command to stop the target\nand then try again."

236,777 (gdb)

238,277 &"Quit\n"

238,777 53-interpreter-exec --thread-group i1 console kill

238,777 &"Quit\n"

238,778 ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n"

238,779 &"Cannot execute this command while the target is running.\n"

238,779 &"Use the \"interrupt\" command to stop the target\n"

238,779 &"and then try again.\n"

238,779 53^error,msg="Cannot execute this command while the target is running.\nUse the \"interrupt\\

" command to stop the target\nand then try again."

238,779 (gdb)


------------------ GDB traces – Linux host ------------------

300,506 2-gdb-version

300,508 ~"GNU gdb (Ubuntu 8.1-0ubuntu3)\n"

300,511 ~"Copyright (C) 2018 Free Software Foundation, Inc.\n"

300,511 ~"License GPLv3+: GNU GPL version 3 or later <>\nThis is fre\

e software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitt\

ed by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"

300,511 ~"This GDB was configured as \"x86_64-linux-gnu\".\nType \"show configuration\" for configur\

ation details."

300,511 ~"\nFor bug reporting instructions, please see:\n"

300,511 ~"<>.\n"

300,511 ~"Find the GDB manual and other documentation resources online at:\n<\


300,511 ~"For help, type \"help\".\n"

300,511 ~"Type \"apropos word\" to search for commands related to \"word\".\n"

300,511 2^done

300,512 3-list-thread-groups

300,512 (gdb)

300,512 3^done,groups=[{id="i1",type="process"}]

300,512 (gdb)

300,512 4-environment-cd xxx/X

300,518 4^done

300,518 (gdb)

300,518 5-gdb-set breakpoint pending on

300,518 5^done

300,518 (gdb)

300,519 6-gdb-set detach-on-fork on

300,519 6^done

300,519 (gdb)

300,519 7-enable-pretty-printing

300,519 7^done

300,519 (gdb)

300,519 8-gdb-set python print-stack none

300,519 8^done

300,519 (gdb)

300,519 9-gdb-set print object on

300,519 9^done

300,519 (gdb)

300,519 10-gdb-set print sevenbit-strings on

300,519 10^done

300,519 (gdb)

300,520 11-gdb-set host-charset UTF-8

300,520 11^done

300,520 (gdb)

300,520 12-gdb-set target-charset UTF-8

300,520 12^done

300,520 (gdb)

300,520 13-gdb-set target-wide-charset UTF-32

300,520 13^done

300,520 (gdb)

300,523 14-gdb-set dprintf-style call

300,523 14^done

300,523 (gdb)

300,524 15source .gdbinit

300,524 &"source .gdbinit\n"

300,524 &".gdbinit: No such file or directory.\n"

300,524 15^error,msg=".gdbinit: No such file or directory."

300,524 (gdb)

300,524 16-gdb-set target-async on

300,524 16^done

300,524 (gdb)

300,524 17-gdb-set record full stop-at-limit off

300,524 17^done

300,524 (gdb)

300,525 18-gdb-set auto-solib-add on

300,525 18^done

300,525 (gdb)

300,528 19-file-exec-and-symbols --thread-group i1 xxx/X/Debug/X

300,530 19^done

300,530 (gdb)

300,530 20-gdb-show --thread-group i1 language

300,531 20^done,value="auto"

300,531 (gdb)

300,531 21-gdb-set --thread-group i1 language c

300,531 21^done

300,531 (gdb)

300,531 22-interpreter-exec --thread-group i1 console "p/x (char)-1"

300,531 ~"$1 = 0xff\n"

300,531 22^done

300,531 (gdb)

300,531 23-data-evaluate-_expression_ --thread-group i1 "sizeof (void*)"

300,532 23^done,value="8"

300,532 (gdb)

300,532 24-gdb-set --thread-group i1 language auto

300,532 24^done

300,532 (gdb)

300,532 25-interpreter-exec --thread-group i1 console "show endian"

300,532 ~"The target endianness is set automatically (currently little endian)\n"

300,533 25^done

300,533 (gdb)

300,533 26-break-insert -t -f main

300,533 26^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400501",\



300,533 (gdb)

300,534 27-inferior-tty-set --thread-group i1 /dev/pts/22

300,534 27^done

300,534 (gdb)

300,535 28-exec-run --thread-group i1

300,537 =thread-group-started,id="i1",pid="29357"

300,537 =thread-created,id="1",group-id="i1"

300,539 29-list-thread-groups

300,570 =library-loaded,id="/lib64/",target-name="/lib64/",h\



300,584 28^running

300,584 *running,thread-id="all"

300,584 (gdb)

300,584 29^done,groups=[{id="i1",type="process",pid="29357",executable="xxx/X/Debug/X",cores=["3"]}]

300,584 (gdb)

300,587 =library-loaded,id="/lib/x86_64-linux-gnu/",target-name="/lib/x86_64-linux-gnu/libc\



300,755 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000\



300,755 ~"\n"

300,755 ~"Temporary breakpoint 1, main () at ../src/X.c:15\n"

300,755 ~"15\t\tputs(\"!!!Hello World!!!\"); /* prints !!!Hello World!!! */\n"

300,755 *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x0000000000400501",func\



300,755 =breakpoint-deleted,id="1"

300,760 30-list-thread-groups

300,760 30^done,groups=[{id="i1",type="process",pid="29357",executable="xxx/X/Debug/X",cores=["3"]}]

300,760 (gdb)

300,933 31-list-thread-groups i1

300,934 31^done,threads=[{id="1",target-id="process 29357",name="X",frame={level="0",addr="0x0000000\



300,934 (gdb)

300,937 32-stack-info-depth --thread 1 11

300,938 32^done,depth="1"

300,938 (gdb)

300,952 33-stack-select-frame --thread 1 0

300,952 33^done

300,952 (gdb)

300,980 34-list-thread-groups

300,980 35-thread-info 1

300,980 34^done,groups=[{id="i1",type="process",pid="29357",executable="xxx/X/Debug/X",cores=["3"]}]

300,980 (gdb)

300,980 35^done,threads=[{id="1",target-id="process 29357",name="X",frame={level="0",addr="0x0000000\



300,980 (gdb)

301,016 36-stack-list-locals --thread 1 --frame 0 1

301,016 36^done,locals=[]

301,016 (gdb)


//***** I don't see the execution of the python script being logged here. *****//

//***** But I guess it has something to do with the separate channel used by the Debugger Console.  *****//

//***** Anyway... Resuming from 'main'  *****//

350,925 37-exec-continue --thread 1

350,925 37^running

350,925 *running,thread-id="all"

350,925 (gdb)

350,948 38-thread-select 1

350,948 38^done,new-thread-id="1"

350,948 (gdb)


//***** Suspending from Eclipse. 'continue' gets executed from the script. *****//

//***** Compared to the behavior on Windows, I now see some empty stack frames in Debug view. We should see the app running in Eclipse. *****//

358,295 39-exec-interrupt --thread 1

358,296 39^done

358,296 (gdb)

358,296 ~"\nProgram"

358,296 ~" received signal SIGINT, Interrupt.\n"

358,296 ~"main () at ../src/X.c:16\n"

358,296 ~"16\t\twhile (1) { };\n"

358,296 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={add\


358,296 ~"Executing <continue>\n"

358,296 ^running

358,296 *running,thread-id="all"

358,300 40-stack-info-depth --thread 1 11

358,300 40^error,msg="Selected thread is running."

358,300 (gdb)

358,300 41-stack-list-frames --thread 1 0 10

358,300 41^error,msg="Selected thread is running."

358,300 (gdb)

358,304 42-stack-select-frame --thread 1 0

358,305 42^error,msg="Selected thread is running."

358,305 (gdb)

358,334 43-stack-info-depth --thread 1 2

358,334 43^error,msg="Selected thread is running."

358,335 (gdb)

358,335 44-stack-list-frames --thread 1 0 1

358,335 44^error,msg="Selected thread is running."

358,335 (gdb)

358,379 45-list-thread-groups

358,379 46-thread-info 1

358,381 45^done,groups=[{id="i1",type="process",pid="29357",executable="xxx/X/Debug/X",cores=["1"]}]

358,381 (gdb)

358,381 46^done,threads=[{id="1",target-id="process 29357",name="X",state="running",core="1"}]

358,381 (gdb)

358,382 47-stack-info-depth --thread 1 5

358,382 48-stack-list-locals --thread 1 --frame 0 1

358,382 47^error,msg="Selected thread is running."

358,383 (gdb)

358,383 48^error,msg="Selected thread is running."

358,383 (gdb)

358,383 49-stack-list-frames --thread 1 0 4

358,383 49^error,msg="Selected thread is running."

358,383 50-stack-list-locals --thread 1 --frame 0 0

358,383 (gdb)

358,383 50^error,msg="Selected thread is running."

358,383 (gdb)

358,386 51-stack-list-frames --thread 1

358,386 51^error,msg="Selected thread is running."

358,386 (gdb)

358,386 52-stack-list-frames --thread 1 1 1

358,386 53-stack-list-frames --thread 1 2 2

358,386 54-stack-list-frames --thread 1 3 3

358,386 55-stack-list-frames --thread 1 4 4

358,386 52^error,msg="Selected thread is running."

358,386 (gdb)

358,386 53^error,msg="Selected thread is running."

358,386 (gdb)

358,386 54^error,msg="Selected thread is running."

358,386 (gdb)

358,386 55^error,msg="Selected thread is running."

358,386 (gdb)


//***** Suspending again is not possible. Eclipse 'sees' the app as suspended, even though it is really executing. *****//

//***** Attempting a Terminate now. Surprisingly, debug session is terminated without any errors popping out. *****//

379,674 56-interpreter-exec --thread-group i1 console kill

379,674 ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n"

379,674 =thread-exited,id="1",group-id="i1"

379,674 =thread-group-exited,id="i1"

379,674 56^done

379,674 (gdb)

379,677 57-list-thread-groups i1

379,678 57^done,threads=[]

379,678 (gdb)

379,682 58-list-thread-groups

379,682 58^done,groups=[{id="i1",type="process",executable="xxx/X/Debug/\


379,682 (gdb)

379,694 59-list-thread-groups

379,694 59^done,groups=[{id="i1",type="process",executable="xxx/X/Debug/\


379,694 (gdb)

380,175 60-gdb-exit

380,175 60^exit


From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Thursday, April 23, 2020 7:39 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse


Caution: EXT Email

Hi Adrian,


This is an interesting use case. Thanks for posting it. The first step to understand why CDT goes wrong is to examine the MI log in this case. Can you share the MI log? 





On Thu., Apr. 23, 2020, 11:55 Adrian Oltean wrote:

Hi everyone,


I’m currently experiencing some problems with regards to how CDT behaves

in the use case described in detail below. Looks like a 'continue' executed

via GDB's python API (see gdb.post_event(event)) somehow confuses Eclipse.


How to easily reproduce the problem:

1. Use an Ubuntu/Windows host;

2. Install Eclipse C/C++ 2019.12;

3. Create a C 'hello world' app for testing; add an infinite loop in 'main';

4. Build the app;

5. Create a python script (e.g. and paste the following code.

Make sure to properly indent it if it gets messed-up in this email;

import gdb


class CustomEvent(object):

    def __init__(self, command):

        self.command = command


    def __call__(self):

        print("Executing <%s>" % self.command)

        gdb.execute(self.command, False, False)


counter = 0

def suspend_handler(event):

    global counter

    if counter % 2 == 0:


    counter = counter + 1


# This is not part of the suspend_handler...


6. Start local debug; use GDB 8+ in all-stop mode;

7. Run the py script using the Debugger Console - 'source';

8. Resume the app from 'main'

9. Suspend execution - note that a 'continue' will (eventually) be executed

from the script. We have two behaviors, depending on the host OS:

  a. On Linux ('enhanced' console supported), Eclipse ends-up in a weird

state, Debug view showing the app suspended (with empty stack frames) whilst

the actual app is running. Suspend button is now disabled. If I try to resume,

I obviously get an error - 'selected thread is running';

  b. On Windows (no 'enhanced' debugger console support, thus no mi-async,

nor target-sync enabled), suspend operation fails with 'operation timeout'. Things

get really messy if trying other operations afterwards.

10. Repeat steps 8 and 9 if problem not reproduced after the first attempt. Seems

to be more reliable on Linux hosts but consistently failing on Windows;


I'm mentioning the 'enhanced' console support because problems seem to be related

to how app/target is interrupted - '-exec-interrupt' vs. kill(SIGINT).


From my experiments, if I switch to non-stop mode GDB, behavior on Linux does not

change, whereas on Windows I no longer see any issues. But on Windows, my setup

involves an ARM-based target, a custom GDB server and JTAG debugging. On my

Ubuntu 18.04 I simply debug a host Linux app.


Anyone else seeing this? Any hints on how to make CDT properly deal with

'continue' executed from a gdb.post_event()?


Thank you,



cdt-dev mailing list
To unsubscribe from this list, visit

cdt-dev mailing list
To unsubscribe from this list, visit

cdt-dev mailing list
To unsubscribe from this list, visit

cdt-dev mailing list
To unsubscribe from this list, visit

cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top