C++ Debugging?

[medvedm]

Has any one EVER successfully debugged a C++ program remotely using TC?  I upgraded to TC 3.4 today and the newest GDB package (7.2, thanks gutenmench), but I am still having zero luck.

Forget Eclipse, I'm just tying to use gdb to debug the simplest of programs (hello world) and I keep getting a segmentation fault.  My host machine is Ubuntu 10.10.

Anyone ever had luck doing what I'm trying to do?

[medvedm]

OK, here is some more info.  I compile and link my C++ hello world app on my Ubuntu box, then I throw it over to my TC 3.4 VirtualBox.  If I open one terminal and run gdbserver, and then run gdb (using the remote target localhost) in another terminal, I can run it just fine. 

If I try to debug it remotely using gdb I get system segmentation errors.  Shared libraries maybe?  Any thoughts?

[gerald_clark]

What makes you think a program compiled on ubuntu will run on TC?

[Jakob Bysewski]

Maybe you can post the output of

Code: [Select]

ldd hello
which will show us the used shared libraries and the ones that are possibly missing. I'd suppose some kind of version missmatch.

You could also try to link your pragram statically, but this is not usefull for programs that make heavy use of libraries

Code: [Select]

g++ -static hello.cpp -o hello


[medvedm]

What makes you think a program compiled on ubuntu will run on TC?

The program compiled on Ubuntu runs perfectly fine on TC.  It is all Linux, and it appears the shared libraries the program uses (basic ones like libstdc++ and the like) are close enough. 

The problem is debugging the program.

[medvedm]

Maybe you can post the output of

Code: [Select]

ldd hello
which will show us the used shared libraries and the ones that are possibly missing. I'd suppose some kind of version missmatch.

You could also try to link your pragram statically, but this is not usefull for programs that make heavy use of libraries

Code: [Select]

g++ -static hello.cpp -o hello


Just as a note I did the -static option and it totally worked.  I was able to debug it remotely, so it is obviously something to do with the libraries.  Linking statically did increase the size of my executable by an order of magnitude (and then times two), so it may not be a practical solution in the long run. 

Here is the output ldd for my executable w/o the static flag:

Code: [Select]

ldd ./HelloWorld
linux-gate.so.1 =>  (0x00955000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x009f3000)
libm.so.6 => /lib/libm.so.6 (0x00e75000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x009ca000)
libc.so.6 => /lib/libc.so.6 (0x005d5000)
/lib/ld-linux.so.2 (0x00188000)


[tinypoodle]

Just as a note I did the -static option and it totally worked.  I was able to debug it remotely, so it is obviously something to do with the libraries.  Linking statically did increase the size of my executable by an order of magnitude (and then times two), so it may not be a practical solution in the long run. 

But that's your best bet to optimize chances of compatibility for a universal Linux binary.

[gerald_clark]

Why dont you just compile in on TC?

[medvedm]

Because I work in Eclipse, which integrates much more than just the compiler into one IDE. 

[medvedm]

Just as a note I did the -static option and it totally worked.  I was able to debug it remotely, so it is obviously something to do with the libraries.  Linking statically did increase the size of my executable by an order of magnitude (and then times two), so it may not be a practical solution in the long run. 

But that's your best bet to optimize chances of compatibility for a universal Linux binary.

Yeah, you're right.  Size isn't really an issue, I suppose.  Also, you have to get the order of the libraries right when you link statically.  It is a bit finnicky.