17

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?

Adam Miller
  • 1,756
  • 1
  • 25
  • 44

3 Answers3

4

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?

Community
  • 1
  • 1
Adam Miller
  • 1,756
  • 1
  • 25
  • 44
  • Hi Adam, any answer yet ? – ransh Feb 19 '15 at 20:30
  • Well I guess what I'm looking for is for the eclipse CDT developers to take notice of what I had to say; I'm not an eclipse programmer. A button of some sort would've been nice – Adam Miller Feb 19 '15 at 21:53
  • Thanks, did you also see behaviour that after removing all breakpoints it still stops at the same place ? – ransh Feb 20 '15 at 05:17
  • I don't know exactly what you're asking. The point is with concurrent code *without* thread locking, if you set a breakpoint, and any situation where the debugger intervenes and stops execution occurs, you can never control the entire concurrent system as a whole very well at all. So if I put a breakpoint in thread 1.cpp (class local only to that thread), and thread 2 is executing concurrently to thread 1; after I stop thread 1, once I start it again, thread 2 will execute every time I hit next in thread 1. I want granular, per thread control (scheduler locking). This is wonky in eclipse – Adam Miller Feb 20 '15 at 19:20
3

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
0

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