Re: [CRIS] dwarf2 frame sniffer problem?

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Tue, 16 Mar 2004 17:27:09 -0500
> From: 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>
> > > 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.

*When* do things go wrong?  Is it all gdb run-type commands all
the time, or is it just when (manually) looking around after
(manually) doing "stepi" into the prologue but not out of it?
Something else?  Just curious in case you have the answer at
hand; I'll try and pursue splitting up EH & debug info.

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

Yeah, flag_asynchronous_unwind_tables means all that.  ISTR Java
and Ada uses that, or should.

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

Opportunities for improvements in the failure mode here? ;-)

brgds, H-P