Eclipse CDT multithreaded debugging not-optimal - how does one run threads exclusively? - c++

Question

I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?

Answer 1

At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?

Answer 2

Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end

Answer 3

My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit