Mail Archives: djgpp/2001/06/25/09:10:10
On Mon, 25 Jun 2001, Graaagh the Mighty wrote:
> On Sun, 24 Jun 2001 10:35:20 +0300 (IDT), Eli Zaretskii
> <eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>
> >Why do you insist speculating instead of stepping with a debugger into
> >the code
>
> In this case, I'd be stepping for hours with the debuggers that
> actually seem to work at all.
Why is that? Is it because the crashes happen after a lot of
processing? Does the crash happen predictably given some specific usage
scenario?
> >It doesn't matter; -gstabs+ is better even without optimizations, when
> >you have tricky bugs like this one.
>
> ISTR discussing this in connection with g++ a few months back, and the
> conclusion was that stabs debugging info was theoretically better but
> not available/broken/something else for some reason. Has this changed?
stabs debugging is better because the compiler generates much more
detailed info, including more detailed line number information and other
important data.
> If it has, why is it not the default format with -g now?
Because simify doesn't support stabs, for starters. And because support
for a better debug unfo format, called dwarf2, is in the works.
> With the other misbehaving program, FSDB
> wouldn't so much as run, AFAICT -- it died at startup with a segfault
> without ever reaching its UI to let me single step anything
That could be because you have DJGPP v2.02. I think FSDB shipped with
that version indeed crashed at startup.
> and RHGDB
> just quietly exited without any error message or normal output (IMO
> both of these indicate bugs in the respective programs -- anything
> that segfaults is buggy regardless of if it only happens with
> "pathological" user inputs, and anything that silently fails
> likewise).
Is this the latest RHGDB? I'd suggest to get the latest versions of all
the debuggers, including GDB 5.0. The debug support in DJGPP v2.03 is
_much_ better, including support for signals, exceptions, FP code
debugging, etc.
- Raw text -