This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [CRIS] dwarf2 frame sniffer problem?


On Wed, Mar 17, 2004 at 12:38:00AM +0100, Hans-Peter Nilsson wrote:
> > 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.

When you use "next", at a function call, GDB will step - then after
that instruction, it will try to find the frame ID.  And then it will
unwind to find the caller's frame ID, and step or breakpoint/continue
until we get back there.  So you've lost if you don't have the ability
to unwind at the first instruction.

Same if you "step" over something you don't have debug info for.

I'm sure there are more things that will go wrong; I don't know how
much.

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

Not really.  You have unwind info; we have to either trust it, or not.
It's not failing to unwind, it's unwinding and providing incorrect
information...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]