Re: Support Dwarf3 DW_CFA_val_* expressions

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 07, 2006 at 02:46:00PM -0300, Alexandre Oliva wrote:
> Using the address of the first instruction in the region wouldn't work
> either.  The hand-generated unwind info arranges for _L_mutex_lock_31
> on i386 to seem like it calls itself, for some reason I don't quite
> understand.  Jakub says the backtrace we get after my change is
> correct, whereas *without* the patch we get this:

Where does this hand generated unwind info come from?  The NPTL I'm
looking at doesn't have any for that function, either an older build I
had around or a current CVS checkout.  I'm very suspicious of your
description of it.

> > In any case, the frame ID should only change when
> > we really enter a different frame.
> 
> My understanding is that the intention *is* to represent debug info as
> an entry into a new frame, but I don't quite understand why it would
> be correct to have two entries for the same function, as in the stack
> trace below (generated by the incorrectly-patched GDB).

If the intention is to represent an entry into a new frame, then the
debugger should be displaying two frames.

> Tricky.  The very point of the tests is to test the complex CFA
> expressions.  I could easily remove all of the cleanup and run-time
> unwinding stuff (is this what you meant?), but taking out the hairy
> bits would render the test pointless.

Testing hand-written dwarf2/dwarf3 is entirely fine, even if we have to
arch-restrict the tests.

-- 
Daniel Jacobowitz
CodeSourcery