Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Eclipse/CDT, GDB and MacOS 11.4/BigSur

  - Good news :), kinda :( … one can have Eclipse/CDT start and stop GDB 10.2 on MacOS, and start inferior threads (processes attached to by gdb).  Trouble is, the entire GDB context is decoupled from Eclipse/CDT, as the MI interface isn’t used with the technique.   Just to see Eclipse/CDT - GDB working, I did the following:

1) created an external tools configuration, and used the variables section to manually give the name of the application of the Eclipse/CDT project

2) ran the gdb and was able to control the application with break-points and execution control commands.  The application was specifically loaded as an inferior thread, akin to what I think the MI technique is attempting. 

   Problems encountered needing resolution for the MI managed Local/Attach scenarios of Eclipse/CDT … with the results from these issues that now Eclipse/CDT on MacOS/BigSur with GDB (even LLDB)  seems completely unusable as an IDE.  One has to fall back to a somewhat decoupled development/debug process if they are to use these tools. 

a. Startup commands of -nx stop the loading of user scripts, yet - appears users scripts have been prescribed as a way to deal with inferior threads starting from the GDB startup sequence Eclipse/CDT has been using in the past.
b. Gdb instructions for code-signing appear to need the ability to have instructions changed to enable debugging ‘attached’ processes

c. Using either local or attach-process Debug configurations results in GDB null-ptr issue

d. Attaching to a process with Eclipse/CDT results in the following (likely due to item ‘b’ above, yet message is not clearly stating

e. Eclipse/CDT has no way to add command lines options to the GDB, and ’nx’ disables scripts.  Accidentally realized this when I was seeing the GDB behavior with command lines, and realizing the Debug Console wasn’t showing the same.  Finally realizing that the options I added after the ‘gdb’ executable are not put in the command line that starts the GDB process.

f. Some MI2 issue, that I still need to obtain logs to diagnose the sequence that leads to the null-ptr in GDB


— prior — 

On Jun 22, 2021, at 8:29 PM, Sam Warner via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:

Hi Jonah,

  Well  "-ix /Users/sam/eclipse-workspace/gdbinit” added to the command line enables the “set startup-with-shell off” to be given despite the “—nx”.  Doesn’t work around the GDB null-ptr issue sadly.  Something else from Eclipse/CDT startup is forcing the inferior thread issue of GDB.

  Worstcase, soon I’ll have a build environment for Eclipse/CDT and can try the Mi3, along with analyze the MI communications from the log.


On Jun 22, 2021, at 7:31 PM, Sam Warner via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:

Hi Jonah,

  While rebuilding I saw this little note (attached)
<Screen Shot 2021-06-22 at 7.24.52 PM.png>

  Roughly, the “NX” is stopping the “.gdbinit” override, and forcing the starting thread to be inferior, which in turn is exposing the GDB issue (Assertion `current_thread_ != nullptr’ failed).  I am going to look for a command line to add to the startup to get the same effect as “set startup-with-shell off


Ps, the Mi override will be helpful for me if I repeat my prior issue of Eclipse/CDT and GDB’s state-machines getting out-of-sync.  The logging info you provided will too. I’m gambling that Mi3 is backward compatible, and that the above bug will be easier to resolve if we can reproduce in Mi3

On Jun 22, 2021, at 6:59 PM, Sam Warner via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:

Hi Jonah,

  - great info - thank you.

  Yep, I confirmed the issue is only presently happening when Eclipse/CDT starts GDB.  It’s a GDB issue though.  I’ll use the traces to look into this further.  Someone’s posted a patch for this issue on GDB, and yep, I will need to a GDB image to get this, as I am pulling from Homebrew.

   Any way - manually - for me to configure to use ‘mi3’ when Eclipse/CDT launches GDB just to see?

Ps, I’ll follow the other information shortly (matters, setup build env, filing bug (if after building with the patch things aren’t resolved).
Pps, I’ll try lldb too

On Jun 22, 2021, at 6:35 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi Sam,

Not a problem at all. Let me see if I can answer your queries inline below.

On Tue, 22 Jun 2021 at 20:03, Sam Warner <samuel.r.warner@xxxxxx> wrote:
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 -

   Any way to alter this to other MI interfaces manually, to see if another just works - before I dive deeper?

Background: MI is short for machine interface (just in case you didn't know). The 2 is the version number of the protocol. GDB has been on version 2 for a long time, but recently added a version 3. Version 3 is mostly the same as version 2, but with some protocol errors from version 2 fixed. See 

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 then you can start gdb in a terminal (with  --interpreter mi2)


Ps, does the team have Slack/Teams or some other equivalent method for questions/answers ?

There is a very underused (by CDT) mattermost channel - we can certainly chat on there.

pps, I am going to need some info on the build setup/environment for Eclipse/CDT too, so any pointers? - Try the Oomph instructions first ( if you are not familiar with setting up Eclipse dev environments.

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". 

<Screen Shot 2021-06-22 at 4.44.56 PM.png>

 What will be interesting about the above screenshot is what sequence of MI commands leads to that assertion.
<Screen Shot 2021-06-22 at 4.39.13 PM.png>

Cool to see new features of CDT being used already -

Let me know what else I can do to help you.



On Apr 9, 2021, at 10:26 AM, Sam Warner via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:

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.


On Apr 9, 2021, at 7:27 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hello folks,

See you all on Wednesday for our monthly call:

CDT Monthly Call April 14 2021

  1. Welcome and sign yourself in
  2. Actions from last meeting
  3. CDT 10.3 / 2020-06 planning (M1 is on 12 April)
  4. Increasing minimum version of GDB we test and support “officially” Bug 572582
  5. Reenabling long disabled DSF-GDB tests (these were initially disabled when we moved to Jiro)
  6. Status of cdt-gdb-adapter
  7. Any other business?

Jonah Graham
Kichwa Coders
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