Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra <amodra@bigpond.net.au>]

On Wed, Jan 07, 2004 at 06:35:59PM -0500, Andrew Cagney wrote:
> >On Wed, Jan 07, 2004 at 06:43:10PM +0100, Mark Kettenis wrote:
> >
> >>If I read your patch correctly, this fixes normal DWARF 2 debugging
> >>info to use the official System V register numbers, but lets GCC
> >>continue to use its own numbering for the Call Frame Info (CFI) in
> >>both the .eh_frame and .debug_frame sections. 
> >
> >
> >That's correct.  hppa, hppa64, iq2000 and ns32k all do the same.
> 
> Outch!
> 
> >mips and cris also define DWARF_FRAME_REGNUM, but squinting at the code
> >leads me to believe they will actually use the same register numbers.
> 
> (same as which? gcc or dwarf 2?)

dwarf2, ie. .debug_info and .debug_frame use the same reg numbers.

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

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre