This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Support Dwarf3 DW_CFA_val_* expressions
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: Tue, 07 Mar 2006 02:31:27 -0300
>
> On Mar 4, 2006, Daniel Jacobowitz <drow@false.org> wrote:
>
> > On Sat, Mar 04, 2006 at 09:01:43AM -0300, Alexandre Oliva wrote:
> >> > It's also good to have a few testcases,
> >> > but I don't completely understand the testcases :(
> >>
> >> You're not alone in that feeling, I assure you :-)
>
> > Like Mark, I am happier with the code than the testcases. In fact,
> > I'd rather not have the tests at all than have something quite
> > so overkill.
>
> Fair enough... Those tests uncovered a problem with the way our
> dwarf2 code identifies frames, though: it uses the function start
> address and the CFA to identify a stack frame, whereas it should use
> the PC and the CFA.
Nope, using the function address is the correct thing to do.
Otherwise you'll end up with a different frame ID if you single-step
to the next instruction for example.
> In some corner cases, such as the one exercised by the i386
> testcase, if you're on the second instruction of the region covered
> by the hand-generated unwind info and ask for a backtrace, GDB
> complains that the stack is corrupt, but the only problem is that
> the dwarf2 machinery gets confused by the same-CFA, same-function
> pair of stack frames. This is fixed in the revised patch below.
That fix is wrong! Either your hand-generated unwind info is wrong
(or incomplete) or GDB needs to do something more clever (like perhaps
using the address of the first instruction in the region covered by
the unwind info). In any case, the frame ID should only change when
we really enter a different frame.
Perhaps you can explain in more detail what the problem is?
> > And you're not correct that older GCCs could run them
> > far enough to test; they'll fail to build because of the use of
> > __attribute__((cleanup))
>
> Oops, indeed, sorry about that. The testcases must definitely be
> amended if they're to remain. Should they?
I think the tests need to be simplified.
Mark