Gus Wirth wrote:
I'm trying to debug a a program called MP4Client which is an MP4 video
player, part of a multi-media package called GPAC <gpac.sourceforge.net>
I am using the source checked out from cvs, and when I do the build,
everything seems to go OK.
Now when I try to run the program, I get a small display window, CPU
load goes to 97% and it just sits there. Fine, I think to myself, I'll
just get a debugger and dive into it. Since I've done little with C I'm
not familiar with it's debugging tools, but I have done a lot with
another language (Delphi), so I thought something like ddd would help.
Why, after more than 20 years of existence, are the debuggers so
primitive (rhetorical question, GNU's not Unix ...)?
A) Because developing on gdb is *very* hard.
B) Because the x86 architecture sucks.
The main problem is just that developing something like gdb is hard. It
requires initimate knowledge of processor architecture, binary API's,
and linkers. There just aren't that many people capable of doing that,
and they normally get paid by companies.
The second problem is that since x86 has historically been register
starved, it doesn't bother to keep a "frame pointer" which allows
tracking the stack, adding extra intercepts, etc.
So, in order to provide a backtrace, gdb needs to have intimate
knowledge of the binary API of the compiler/linker. Fortunately, these
are normally GNU. However, every time that API changes, gdb breaks.
Oh, and if something actually went wrong on the call stack, everything
is screwed.
All of this stuff channels off the abilities of people who can actually
develop gdb (*very* few people) and redirects them into the black hole
of maintenance.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
