| Re: [cdt-dev] [EXT] Re: 'continue' executed via gdb.post_event() breaks run control inside Eclipse |
Hi Jonah,
Sorry for completely abandoning the old discussion I started a while ago but I really gave up adopting GDB 8.3 in the product at that point. And then I completely forgot to reply on the thread…
The changes we discussed back then, helped to some extent but I had lots of use cases that exhibited weird behaviors. So, not being able to make GDB (with the python scripts layer I have) properly interact with CDT was a no go for me. But I decided to try an upgrade to GDB 11 now. I’ll summarize the relevant components in my product and what changes I’ve done so far for integrating GDB 11:
- I’m still using Eclipse 4.14 + CDT 9.10, but maybe I’ll try to update these as well (if I manage to see that integration with GDB 11 turns out to be OK).
- CDT 9.10 has some code in the GDB backend service that links/assimilates the ‘full GDB’ console support with target async enablement. However, I noticed this code slightly changed recently, decoupling the two concepts. In my setup I patched the backend service to completely disable target-async and ‘full GDB’ console support. It could be because of my environment, but I can’t make CDT & GDB interact correctly otherwise.
- In the GDB server, I had to implement and respond to some RSP packets (e.g. ‘qC’) and inject the PID in the responses that involved a ‘thread-id’ element. The GDB server I have does not support multi-process debug, but if PID is omitted, GDB takes some weird decisions in multi-threaded debug use cases. Adding the PID might be considered a work-around but seems to address the problems I’ve seen on my side.
- In the GDB client, after spending a lot of time debugging it, I came up with the patch I referred on GDB mailing list. Without those changes, I’ve seen GDB completely ignoring interrupt requests (Ctrl+C or ‘interrupt’ / ‘-exec-interrupt’) in some use cases.
- There’s also the semihosting issue I described but I think I’ll work-around that as well by ignoring the ‘H’ packet in that particular case. I hope someone can comment on the GDB mail thread.
To summarize, that’s what I’ve done so far. I’m currently doing some in-depth testing and hoping to see that no other problems arise.
Regarding the CDT changes we discussed in the previous emails, I’ll need to check first how the latest CDT behaves when using GDB 11 in that particular use case. This is not something that I’ve done till now but I promise to come back with a reply once I have a conclusion. Ideally, by the end of March I should have a working product with the components I mentioned above.
Thank you,
Adrian
From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: Monday, March 7, 2022 9:48 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Cc: Adrian Oltean <adrian.oltean@xxxxxxx>
Subject: [EXT] Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse
Caution: EXT Email
Hi Adrian,
Did you make much progress on this? Do you have a patch for CDT?
I noticed you were working on some GDB patches[1] and hoping that the CDT community can benefit from some of the improvements you are making. (Sorry I don't know enough to answer your question on the GDB side)
Thanks
Jonah
On Mon, 27 Apr 2020 at 14:38, Adrian Oltean <adrian.oltean@xxxxxxx> wrote:
Understood. I thought that there are some mechanisms in place that can be reused for checking for an active suspend operation.
Also, I’ll follow-up up on this thread once I have the polished CDT patch.
Thanks again,
Adrian
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Monday, April 27, 2020 8:43 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
There are a few situations that DSF interrupts the target (check call hierarchy for Spawner.interruptCTRLC()). But the basic flow is to wrap these methods (such as GDBRunControl_7_12.suspend() with a request monitor so you know when the suspend is running. Here is some (pseudo)code:
suspending = true;
suspend(context, new RequestMonitor(getExecutor(), rm) {
@Override
protected void handleCompleted() {
suspending = false;
super.handleCompleted();
}
});
and then use the "suspending" in your checking code.
I am looking forward to you submitting your fix. It probably does apply to other cases where a user does "continue&" in the CLI but DSF is not already in async mode.
HTH,
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
On Mon, 27 Apr 2020 at 13:05, Adrian Oltean wrote:
Regarding the output, from what I noticed, the OOB’s I’m interested in and coming from GDB are instances of MILogStreamOutput. On the other hand, if I were to print a “Quit” from Debugger Console or via a python script, I’d see the OOB’s being MIConsoleStreamOutput objects. So I think we should be safe. However, your suggestion makes sense, but how do I check whether there’s an active interrupt/suspend inside DSF? :-)
The implementation I described, accommodates my environment – I have a custom product based on CDT. This is why I’d like to have everything working there first. Once I’m confident about the changes, I’ll rework and add them directly inside the CDT-DSF source files.
Thanks,
Adrian
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Jonah Graham
Sent: Monday, April 27, 2020 7:12 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 sounds like a reasonable workaround for GDB. I would probably want to have the -exec-interrupt only sent if there is an active attempt by DSF to interrupt the target. That is because I am unsure what else could appear in the output.
The big difference is I wouldn't extend the existing classes, but simply add the code to them and submit that as a gerrit for inclusion in CDT.
Jonah
On Mon, 27 Apr 2020 at 11:59, Adrian Oltean wrote:
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:
- Write an MIQuitEvent class extending MIEvent
- Implement an extension of MIRunControlEventProcessor_7_12 and make sure to return an instance of this via GDBControl_7_12’s createMIRunControlEventProcessor()
- 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
- Once “Quit” is identified, dispatch a new MIQuitEvent on the DSF session
- Extend GDBRunControl_7_12 and make sure to return this via GdbDebugServicesFactory’s createRunControlService()
- 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.
Thanks,
Adrian
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.
HTH,
Jonah
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
this?
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,
Adrian
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.
Thanks,
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
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 - https://sourceware.org/pipermail/gdb/2020-February/048395.html. Maybe it helps.
Thanks,
Adrian
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.
Thanks
Jonah
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?
Thanks,
Adrian
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.
HTH,
Jonah
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. :-)
Thanks,
Adrian
------------------ 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) 8.3.0.20190709-git\n"
176,145 ~"Copyright (C) 2019 Free Software Foundation, Inc.\n"
176,145 ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\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 ~"<http://www.gnu.org/software/gdb/bugs/>.\n"
176,145 ~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/\
software/gdb/documentation/>."
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\
w36_demo_apps_bubble
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\
",fullname="xxx\\frdmkw36_demo\
_apps_bubble\\startup\\startup_mkw36z4.c",line="288",arch="armv6s-m"},thread-id="1",stopped-threads=\
"all"
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\
tal-size="180010"}
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_\
bubble.axf"}]
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\
000124",func="ResetISR",args=[],file="../startup/startup_mkw36z4.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\startup\\startup_mkw\
36z4.c",line="288",arch="armv6s-m"},state="stopped"}]
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=\
"main",file="../source/bubble.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\source\\bubble.c",line="163",thread-groups=["i1"],times\
="0",original-location="main"}
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\
0007c2",func="main",file="../source/bubble.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\source\\bubble.c",line="163",thread-groups\
=["i1"],times="1",original-location="main"}
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",\
args=[],file="../source/bubble.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\source\\bubble.c",line="163",arch="armv6s-m"},thread-i\
d="1",stopped-threads="all"
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",\
"sp","lr","pc","","","","","","","","","","xpsr","","","","","","","","","","","","","","","","","",\
"","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","\
","","","","","","","","","","","","","","","msp","psp","control","primask","cycles"]
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"\
,func="main",args=[],file="../source/bubble.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\source\\bubble.c",line="163",arch="armv6s\
-m"},state="stopped"}]
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 post_event.py"
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/\
fsl_i2c.c:964\n"
212,707 ~"964\t while (!(base->S & kI2C_IntPendingFlag))\n"
212,707 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={add\
r="0x00001d9c",func="I2C_MasterTransferBlocking",args=[{name="base",value="0x40066000"},{name="xfer"\
,value="0x2000bfbc"}],file="../drivers/fsl_i2c.c",fullname="xxx\\frdmkw36_demo_apps_bubble\\drivers\\fsl_i2c.c",line="964",arch="a\
rmv6s-m"},thread-id="1",stopped-threads="all"
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) 8.1.0.20180409-git\n"
300,511 ~"Copyright (C) 2018 Free Software Foundation, Inc.\n"
300,511 ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\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 ~"<http://www.gnu.org/software/gdb/bugs/>.\n"
300,511 ~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/soft\
ware/gdb/documentation/>.\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",\
func="main",file="../src/X.c",fullname="xxx/X/src/X.c",line="15",thread-\
groups=["i1"],times="0",original-location="main"}
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/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",h\
ost-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ff\
ff7dd5f10",to="0x00007ffff7df4b20"}]
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/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc\
.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{fro\
m="0x00007ffff7a052d0",to="0x00007ffff7b7dc3c"}]
300,755 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000\
00000400501",func="main",file="../src/X.c",fullname="xxx/X/src/X.c",line\
="15",thread-groups=["i1"],times="1",original-location="main"}
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\
="main",args=[],file="../src/X.c",fullname="xxx/X/src/X.c",line="15"},th\
read-id="1",stopped-threads="all",core="3"
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\
000400501",func="main",args=[],file="../src/X.c",fullname="xxx/X/src/X.c\
",line="15"},state="stopped",core="3"}]
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\
000400501",func="main",args=[],file="../src/X.c",fullname="xxx/X/src/X.c\
",line="15"},state="stopped",core="3"}]
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\
r="0x000000000040050b",func="main",args=[],file="../src/X.c",fullname="xxx/X/src/X.c",line="16"},thread-id="1",stopped-threads="all",core="3"
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/\
X"}]
379,682 (gdb)
379,694 59-list-thread-groups
379,694 59^done,groups=[{id="i1",type="process",executable="xxx/X/Debug/\
X"}]
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?
Thanks,
Jonah
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. post_event.py) 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:
gdb.post_event(CustomEvent("continue"))
counter = counter + 1
# This is not part of the suspend_handler...
gdb.events.stop.connect(suspend_handler)
6. Start local debug; use GDB 8+ in all-stop mode;
7. Run the py script using the Debugger Console - 'source post_event.py';
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,
Adrian
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev