Log in

No account? Create an account
'Twas brillig, and the slithy toves did gyre and gimble in the wabe [entries|archive|friends|userinfo]

[ website | Beware the Jabberwock... ]
[ deviantArt | the-boggyb ]
[ FanFiction | Torkell ]
[ Tumblr | torkellr ]

[Random links| BBC news | Vulture Central | Slashdot | Dangerous Prototypes | LWN | Raspberry Pi]
[Fellow blogs| a Half Empty Glass | the Broken Cube | The Music Jungle | Please remove your feet | A letter from home]
[Other haunts| Un4seen Developments | Jazz 2 Online | EmuTalk.net | Feng's shui]

gdb fail [Friday 11th September 2009 at 8:07 pm]

[Tags|, , ]
[Where |Chichester station]
[Playing |Walled City internet radio]

It never ceases to amaze me just how backward the Linux development environment is.

Today I attempted to debug a test program that segfaults about 5 minutes after startup for no apparent reason. I managed to get a core dump of it, and loaded it into gdb in the hope of finding what was going on. Hahaha.

gdb could give me a valid stack trace showing the error, and could disassemble the program around the error to show me the actual instructions involved. However, gdb could not tell me the value of all the variables there (it claimed that some variables weren't even defined, nevermind that the program uses them all over the place!), nor could it actually match the disassembly up to the source.

Come on, folks, Visual C++ has been able to do this for decades! The Windows debugging tools are so far ahead it's embarassing for Linux.

I did actually discover a patch to gdb to achieve this, submitted April last year. Unfortuantly it's not in the latest released version of gdb (released March last year), and I really don't fancy building gdb from source myself.
Link | Previous Entry | Share | Flag | Next Entry[ 4 pennies | Penny for your thoughts? ]

[User Picture]From: boggyb
Monday 14th September 2009 at 8:21 pm (UTC)
Turned out that the lack of variables was mainly due to optimisation. Presumably gcc's optimiser is a very different beast to MSVC, as when debugging optimised Windows DLLs WinDbg managed to keep track of everything. They still didn't reliably appear with optimisation disabled. Oh, and to get an annotated assembly listing you can use "objdump -S" but only if your debugging information is in Stabs format (which is neither documented nor the default) and your program is not optimised. This allowed me to finally track down the bug (someone declared a function-level temporary variable as static and then used that function as the entry point for 84 threads - the best part is this program worked when it was first used many years ago!)

On frontends... I've played with ddd (a X frontend for gdb), and it's a lot friendlier to use but does require X installed. It still completely failed at showing me the contents of things like std::vector, but that's more of a gripe with their standard library (and I did find a macro for gdb to decode those). I doubt you'll want to install X on your AVR, which leaves you with the wonderfully flaky gdb server system (which is a thin client setup, so you need your symbols on the target, and the remote debugger tended to segfault every time I told it to restart the debuggee).
(Reply) (Parent) (Thread)