Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Dec 16, 2002 at 12:02:57PM -0500, Andrew Cagney wrote:
> >Hi all,
> >this long patch provides a fix for a very annoying fact, that GDB on 
> >x86-64 can't do backtraces from hand-optimized assembler functions (that 
> >applies for example to glibc's memset, str*, etc as well as to syscall 
> >wrappers).
> >This is caused by the lack of a valid debug_frame/eh_frame FDE entry for 
> >such a function (noone really writes .debug_frame section in his assembler 
> >code :-)
> >
> >My approach to fix this behaviour is based on the fortunate fact, that 
> >most of those affected glibc's functions don't touch the stack at all, so 
> >creating an artifical FDE for them is easy.
> 
> If I understand this correctly, you've created create dwarf2cfi info for 
> a function that has no such info.  That way the dwarf2cfi code can 
> unwind a function that doesn't actually have CFI?

That's right.

> If that is the case then I don't think this is either necessary or 
> correct.  A `struct frame_info' allows frame specific unwind functions - 
> at present only dummy-frame and saved-regs-frame versions are 
> implemented, however the next ones to implement are cfi-frame (unwind 
> using CFI info) and regs-frame (unwind using the register cache).
> 
> For your problem, wouldn't it be better to, instead of creating fake CFI 
> info, implement custom frame unwind functions that handle your case?

Hrm.  What do you mean by regs-frame?  If it's for the current frame
wouldn't that be a frame which just doesn't unwind?

As for this situation, and the similar one for i386... there are three
unwind functions, to find the previous frame's registers, ID, and PC.
For this case we just want to express a normal function call which
saves no registers; pretty easy.  But for i386 I'll want to express
something which initially pushes a register, and then does some work,
pops it, and does more work before returning.

There's plenty of ways to express that but it seems to me that the most
useful one would be to have essentially a glorified prologue reader
which builds that description.  Then the machinery to handle that
description is - you guessed it - a standard CFI reader.  It might be
nice to someday split up the CFI parser and executer so that we could
provide the description less obtusely, but I'd hate to see us duplicate
the machinery.


BTW,
    /* See description above.  The previous frame's resume address.
       Save the previous PC in a local cache.  */
    frame_pc_unwind_ftype *pc_unwind;

    /* See description above.  The previous frame's resume address.
       Save the previous PC in a local cache.  */
    frame_id_unwind_ftype *id_unwind;

Second comment is a past-o?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer