Hi Jonah,
Apologize for missing this months meeting. I’ve made some progress, though definitely this has been a bit of a challenge - despite getting to what seems like a productive point. Seems Eclipse/CDT’s is starting up GDB with “—interpreter mi2 and —nx”.
That is as expected :-)
The terminated process shows this info on the MacOS (haven’t tried other OSes). The net of the ‘mi2’ is it appears to not couple to GDB v10.2 properly, I keep getting:
“Gdb/thread.c:95: internal-error: struct….”
as an error message when I start a debug session with a “Local” app. While I am certain we have exposed some GDB flaw, at the moment I am trying to scope out the issue a bit. (See attachments below).
Yes, nothing we have done in CDT should cause GDB to have an internal error, and if possible the bug should indeed be reported to GDB or, if the package was built by someone else, to them (e.g. if you got it from homebrew and the have their own patches that may need to be first port of call -
https://formulae.brew.sh/formula/gdb)
Any way to alter this to other MI interfaces manually, to see if another just works - before I dive deeper?
CDT can only talk to GDB with version mi2. What I do when trying to track down such problems is use the GDB CLI (start gdb without --interpreter argument) to reproduce similar sequences to make sure things work properly.
To create a bug report for GDB you may want to create the minimal sequence of commands that exposes the problem. If you want to see what CDT is sending/receiving with GDB you can turn on the MI traces view (see
https://wiki.eclipse.org/CDT/User/NewIn92#Hide_gdb_traces_by_default) then you can start gdb in a terminal (with
--interpreter mi2)
Sam
Ps, does the team have Slack/Teams or some other equivalent method for questions/answers ?
pps, I am going to need some info on the build setup/environment for Eclipse/CDT too, so any pointers?
ppps, The “—nx” is rather interesting, as I spent quite a while trying to follow the exact directions for installing and coupling GDB to Eclipse/CDT, and the startup command disables the entire startup-script. The interesting part being I kept trying to debut why the startup-script wasnt being used… but … hey…. Call me stupid :). I could have just asked.
The --nx is to ensure nothing from the "external" environment affects the GDB/CDT interface. Many normal settings in .gdbinit files can cause problems. Individual launches can have init files (specified in the launch configuration) and that may be a good place to add the extra items like "set startup-with-shell off".
What will be interesting about the above screenshot is what sequence of MI commands leads to that assertion.
Let me know what else I can do to help you.
Jonah
Hi Johan,
I’d be interested in helping, sorry I hadn’t helped before on the GDB issues I had identified with OS-X. I’ll join the meeting to see how I might be of help, or if you know way beforehand - please do reply back.
Thanks,
Sam
Hello folks,
See you all on Wednesday for our monthly call:
CDT Monthly Call April 14 2021
- Welcome and sign yourself in
- Actions from last meeting
- CDT 10.3 / 2020-06 planning (M1 is on 12 April)
- Increasing minimum version of GDB we test and support “officially” Bug 572582
- Reenabling long disabled DSF-GDB tests (these were initially disabled when we moved to Jiro)
- Status of cdt-gdb-adapter
- Any other business?
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
