Re: [CRIS] dwarf2 frame sniffer problem?

[Hans-Peter Nilsson <hans-peter.nilsson@axis.com>]

> 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?

> 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...

brgds, H-P