Eclipse CDT + GDB: Setting Watchpoints (Juno)

I was trying to watch a variable in Eclipse today and just could not find how to set it up. No matter what I did the Toggle Watchpoint option remained greyed out.

A watchpoint is more fun than a regular breakpoint, because the debugger will stop whenever the variable is changed, even if your program is busy doing something else (like overrunning the end of an array).

So after a bit of research it turns out that you can set watchpoints, but the variable type dictates how.

Global variables

If your variable is global, you need to double-click the variable to highlight it (anywhere in your source) and then select Run > Toggle Watchpoint. Until your variable is selected, this option will always be greyed out.

You can also right click on it in the Outline View and then select Toggle Watchpoint from the context menu.

In both cases a watchpoint properties box pops up so you can edit the details. Just click OK and the debugger will stop every time the variable is changed.

If the variable is not listed in the Outline View then sorry – it’s not global and you can’t use the Eclipse GUI to set it – but you can do this:

Local variables

When you’re debugging with gdb via Eclipse, there is a sneaky gdb console view that you can use to talk directly to the gdb session.

Select the console tab at the bottom and on the right-hand side click the Display Selected Console button. This will reveal a drop down menu. Choose [C/C++ Application] gdb.

And now, in the console itself, just type your watchpoint as if you were on the gdb command line (in the screenshot below I want to be notified if a local variable called count goes above the value of 45):

 

gdb console watchpoint

Ta da! Eclipse will now stop whenever your local variable changes.

Share this:
  • Google Bookmarks
  • Facebook
  • HackerNews
  • Reddit



Sony Vaio No Touchpad Detected in Debian Squeeze

After 10 years on Fedora I have switched to Debian.

There isn’t really a definitive reason for the switch. It was partly that I didn’t really enjoy using FC16 at work and partly the negative reviews I read when looking to upgrade my own machine from FC14 to FC18. But it was also the fact that I just fancied a change.

I installed Debian two days ago onto my Sony Vaio and so far I like it.

However, out of the box my Vaio touchpad didn’t work.

It took me a while to find a fix, so this is what I did in case anyone else stumbles onto a similar problem.

In my case, the touchpad wasn’t being detected by the kernel at all (nothing in /proc/bus/input/devices and no relevant messages in dmesg).

Debian is a bit behind on the kernel – it uses 2.6.32-5.

But my original FC13 install on the Vaio used kernel 2.6.33 and the touchpad worked, so the first thing I did was update the kernel using the Debian backports.

I used a really nifty guide on nixCraft to upgrade to 3.2.0-0.

Once I’d rebooted I had a working touchpad, but no support for tap-to-click (and I love tap-to-click).

To get that working too, after enabling it in System > Preferences > Mouse [Touchpad], I used this solution to “Tap-to-click not working” on the Debian user mailing list.

For me, after rebooting again, tap-to-click and edge scroll were both working fine.

One happy new Debian user :-)

Share this:
  • Google Bookmarks
  • Facebook
  • HackerNews
  • Reddit



GDB: Unable to find dynamic linker breakpoint function.

You all know how much I loooooooove GDB, so what better thing to write about after a long time away?

If you’re seeing this message:

warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

and all your stack frames look like this:

0x40000780 in ?? ()

gdb is trying to tell you that it cannot find the relevant ld library for the target it is debugging.

Huh?

Well, ld (linux-ld.so and ld.so) is responsible for locating and running all the shared libraries required by your executable. You must tell gdb where the target version of ld lives so that it can successfully track what your executable is up to.

You probably already know that when remote debugging you should have an unstripped copy of your target’s root filesystem available on your host. Then you can point gdb to the copy filesystem and it will be able to “see” the target’s files.

And that means a seamless debugging experience :-)

Since ld is a system library, you needn’t add the path to this explicitly. Just point to the “root” of the copy filesystem and gdb is clever enough to find it.

To do this, use the sysroot command:

set sysroot /absolute/path/to/copy/of/target/root/filesystem

You can also use:

set solib-absolute-prefix /absolute/path/to/copy/of/target/root/filesystem

as this is simply an alias for the sysroot command.

Often you will see suggestions to use:

set solib-search-path /path/to/target/root/filesystem

However, this is checked after sysroot and is meant to be used for a list of colon separated paths to non-system libraries that you may be using on your target.

E.g. If you use a shared library from a third party for say, graphics, that isn’t part of the root filesystem, then you can set its path here.

One more tip:

If you are already connected to the target executable (with the target remote <ip:port> command), when you set your paths, you will get a useful confirmation of the libraries that are loaded on each command:

set sysroot /opt/target/root/
Reading symbols from /opt/target/root/lib/ld-linux.so.3...done. 
Loaded symbols for /opt/target/root/lib/ld-linux.so.3
set solib-search-path /home/faye/LIB/target/ 
Reading symbols from /home/faye/LIB/target/libTerrain.so...(no debugging symbols found)...done.
Loaded symbols for /home/faye/LIB/target/libTerrain.so 
Reading symbols from /home/faye/LIB/target/libAlien.so...done. 
Loaded symbols for /home/faye/LIB/target/libAlien.so

Once you know all your paths are set correctly, you can just add these commands to your GDB init file, to save you typing them in each time you run gdb.

Happy debugging :-)

Share this:
  • Google Bookmarks
  • Facebook
  • HackerNews
  • Reddit



Online!

Did ya miss me??

A year has passed and it’s about time I started bothering you all with some little snippets of code again.

So what exactly have I been up to for the last 12 months?

Well, I’ve been mainly looking after my two boys (now 3 and 1.5 years old), but for the last 6 months I have also been actively employed working with my good old friend the marine navigation unit. Lots of C and C++, lots of GDB and a few bits of new technology just to keep things interesting. The combination of these two things has left me no time at all to do much of anything else.

BUT.

Latest news in the Williams household is that I am leaving my secure, happy, multi-threaded post and going on to do… well, at the moment, nothing!

The boys need Mummy around a lot more than I anticipated, and unsurprisingly they are not overly keen on me spending all my time away from home solving complex problems and refactoring code.

So officially, for now, I’ll be a Stay At Home Mum.

But unofficially that means I’ll be spending a bit more time around here and getting to know you all a bit better.

So put the kettle on chuck, and tell me all about yourself…

Share this:
  • Google Bookmarks
  • Facebook
  • HackerNews
  • Reddit



Offline

I’m taking a break in 2012 for a few months (maybe less, maybe more!).

Two boys aged 2 and 4 months fill my days to capacity at the moment.

Keep on coding!

Share this:
  • Google Bookmarks
  • Facebook
  • HackerNews
  • Reddit