This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [CRIS] dwarf2 frame sniffer problem?
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