This is the mail archive of the
mailing list for the GDB project.
Re: Incorrect DWARF-2 register numbers on PPC64?
> Date: Thu, 8 Jan 2004 11:18:49 +1030
> From: Alan Modra <email@example.com>
> > >>This won't work for GDB
> > >>since it assumes that CFI uses the same register number encoding as
> > >>all the other DWARF 2 debug information.
> > >
> > >
> > >Hmm, I can see that a debugger might reasonably expect .debug_frame
> > >to have the same numbers. When I wrote the patch, I was concentrating
> > >on .eh_frame rather than .debug_frame, but .debug_frame uses the
> > >.eh_frame numbering. It's a little perplexing that dwarf2out.c does
> > >this, as it means defining DWARF_FRAME_REGNUM to something other
> > >than DBX_REGISTER_NUMBER is useless. DWARF_FRAME_REGNUM ought to
> > >just effect .eh_frame. I'm not keen on trying to untangle dwarf2out.c
> > >though..
> > Is it going to be possible to get this untangled before 3.4 is
> > branched/released?
> Hmm, I see gdb looks at .eh_frame as well as .debug_frame, so my idea
> of using gcc hard regs for .eh_frame and the proper dwarf regs for
> .debug_frame is probably a non-starter anyway.
> The "easy" fix for PPC is to not define DWARF_FRAME_REGNUM so that
> .eh_frame and .debug_frame use the reg numbers specified by the ABI,
> and to define DWARF_FRAME_REGISTERS as 1232. We can even map "old"
> .eh_frame regs using DWARF_REG_TO_UNWIND_COLUMN, so that older libs can
> be understood by the unwinder, at least as long as they don't use
> altivec regs.
> The only trouble is that this will mean huge unwinder tables.
That will also mean that executables built with a new version of GCC won't
run on operating systems with an old libgcc. For Darwin, because of
historical mistakes involving non-shared libgcc, it will make life
- Geoffrey Keating <firstname.lastname@example.org>