Author Topic: alternative GDB issue  (Read 547 times)

Offline nenin

  • Almost regular
  • **
  • Posts: 227
alternative GDB issue
« on: May 29, 2024, 09:22:56 am »
I tried fresh gdb 14 from
I configured it as "gdb14-64" (see attach 1 ) and assigned it to the toolchain (see attach 1), replacing native gdb form this toolchain, "nix64" (see attach 1).
However,  old "nix64" gdb is jumping out when I`m trying to debug (see attach 1). In default.conf all looks ok (attach 2), when I hacked "nix64" profile to use ssbssa gdb, it worked. Looks like somewhere in depth of the C::B old profile, "nix64", is not replaced with new one "gdb14-64".
"So it goes" (с)
Update: Problem was resolved according to,22724.msg154381.html#msg154381 recommendation. Somehow "nix64" was assigned as "active debugger"  :-X
« Last Edit: May 29, 2024, 09:40:56 am by nenin »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5931
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: alternative GDB issue
« Reply #1 on: May 29, 2024, 02:24:02 pm »
Grad to see you have solved your problem.

I use this GDB for a long time. I think this GDB is better than the Msys2's GDB.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline nenin

  • Almost regular
  • **
  • Posts: 227
Re: alternative GDB issue
« Reply #2 on: May 30, 2024, 09:13:25 am »
For me main surprise was that C::B abandoned default gdb configuration and selected "nix64". It is good feature- manual selection of the actuald debugger-  but when user do it with purpose.  I did not do it, and I`m afraid that there is kind of "slow" corruption of the default.conf 
I`m using  ssbssa gdb from time to time, when update of the gdb in mingw distribution is delayed. It is solid stuff.