This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [CRIS] dwarf2 frame sniffer problem?
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: drow at false dot org
- Cc: orjan dot friberg at axis dot com, gdb-patches at sources dot redhat dot com, hans-peter dot nilsson at axis dot com
- Date: Tue, 16 Mar 2004 21:50:28 +0100
- Subject: Re: [CRIS] dwarf2 frame sniffer problem?
> 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