Re: [CRIS] dwarf2 frame sniffer problem?

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 16, 2004 at 09:50:28PM +0100, Hans-Peter Nilsson wrote:
> > Date: Tue, 16 Mar 2004 14:13:01 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> 
> Hi Dan.
> 
> > On Tue, Mar 16, 2004 at 05:26:16PM +0100, Orjan Friberg wrote:
> > > Would emitting that label *after* the prologue be an option (i.e. 
> > > leaving us without dwarf2 information while still in the prologue)?
> > 
> > Nope.  Then when you step into the prologue (i.e. "step over") unwind
> > information will be incorrect.
> 
> Is that the whole effect, incorrectness for gdb usage *inside*
> the prologue?

Probably yes.  So backtraces will not be affected but every bit of
running is likely to misbehave.

> > I recommend taking a look at the patch where I implemented this for
> > Thumb, or at the m68k implementation.
> 
> I know *how* to do it, I just want to prod a little if there's a
> way to avoid dwarf2 info (specifically advance_loc directives)
> not necessary for EH unwinding and still have it working for gdb
> modulo stepping inside the prologue.  It worked fine until gdb
> started to use dwarf2 too. :-)
> 
> As you know, the same info ends up in the EH unwind info as
> well, and we don't want that to be larger than absolutely
> necessary.  (And as I suppose you *also* know, mentioned for the
> record, "disk is cheap" is definitely not true when the disk is
> solid-state memory.)  Yeah, there should be a way to emit
> different dwarf2 EH from that for debug.  Hmm, maybe it would
> work to just withholding all advance_loc codes except the last
> one for for_eh && !flag_asynchronous_unwind_tables in
> gcc/dwarf2out.c (sort of).  And a target-specific hook for
> "advancing loc", which could use the new gas dwarf2 directives
> so it's not always advance_loc4.  Getting off-topic here...

Yeah, that may be the best way to solve this - emit more info in the
.debug_frame than in .eh_frame, if you aren't supporting asynchronous
unwinding.  Like throwing from signal handlers taken during prologues,
et cetera.

GDB gets _very_ cranky when unwind information is specified but not
correct.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer