Re: [CRIS] dwarf2 frame sniffer problem?

Hans-Peter Nilsson
2004-03-16T20:51:11Z

> 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