Re: backtrace issues

[Joel Brobecker <brobecker@gnat.com>]

> Actually, the fact that the program was compiled with a recent GCC
> seems to be irrelevant.
> 
> I did come up with a stripped-down test case; I've filed PR gdb/1545
> about it.

Note that I have also reported a similar problem with the
pthread_library. With 5.3, GDB was doing an approximate job, and
lost a few frames in the way, but we still had the useful part of
the backtrace more or less intact. With the new frame code, however,
the unwinder just stops :-( and leaves the user with a bactracke which
he can't use.

Given the level of optimization involved in the code from which we
wanted to backtrace from, it was determined that there was very little
that we could do, which is unfortunate because it used to be able
to get out of this quagmire before...

At the time when we discussed this, we argued that the only hope was
with dwarf2 CFI, but it just so happens that I noticed the exact same
sort of problem on Windows XP (where we don't have dwarf-2 :-/).

I have been brooding for a while over this, and really don't see any
solution to this, right now. Maybe it's unfair to say this: I find
the new frame code well structured and blissfully free of all the hacks
we used to have. However, it seems less tolerant to difficult cases,
where we just stop unwinding while we used to be able to have a useful
backtrace with 5.3.

(please don't see this as a complaint or don't think I am pointing
finger at anybody - if I had found a better solution, believe me, 
I would have sent a suggestion).

-- 
Joel