Re: Bogus PPC64 return-colum? Was: [Fwd: Re: [PATCH] S/390 DWARF-2 CFI frame support]

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Jan 01, 2004 at 02:24:08PM +0100, Mark Kettenis wrote:
>    Date: Thu, 1 Jan 2004 21:31:25 +1030
>    From: Alan Modra <amodra@bigpond.net.au>
> 
>    PPC64 (and PPC32) GCC currently ignores the DWARF register numbering,
>    and instead just uses the internal GCC numbering.  It's easy to fix,
>    except that we need some ABI doco changes to accommodate GCC's splitting
>    of cr into fields, but once fixed we run into the problem of what to do
>    about current binaries.  Is it worth hacking gdb to support them?
> 
> I don't think it is worth it.  The current GCC mapping and the DWARF
> mapping specified by the System V use the same register numbers for
> %r0-%r31 and %f0-%f31.  For most of the other registers, I've created
> a table that comparses GCC with current GDB and the System V DWARF
> numbering:
> 
> #	GCC	GDB	SysV
> 
> 64	mq	pc	cr
> 65	lr	ps	fpsr
> 66	ctr	cr	ps
> 67	ap	lr	-
> 68	cr0	ctr	-
> 69	cr1	xer	-
> 70	cr2	fpscr	sr0
> 71	cr3	%v0	...
> 72	cr4	...	...
> 73	cr5	...	...
> 74	cr6	...	...
> 75	cr7	...	...
> 76	xer	...	...
> 77	%v0	...	...
> ..	...	...	...
> 85	...	...	sr15
> ..	...	...	-
> 100	...	...	mq
> 101	...	...	xer
> 102	...	%v31	-
> ..	...	-	-
> 104	...	vrsave	-
> ..	...	-	-
> 108	%v31	-	lr
> 109	-	-	ctr
> 
> 124	-	mq	-

The PowerPC64 ABI extends this table to define a few more regs in the
SPR range 100 thru 1123.  v0 thru v31 are assigned 1124 thru 1155 and
vrsave is 356, which is also the numbering specified in the Altivec PIM.
The SPE ABI defines SPE_ACC as 99 and SPEFSCR as 612.

> We see that GDB doesn't follow the current GCC mapping.  For stabs
> things are fixed up for mq, lr, ctr and xer (not for the other
> registers) but not for DWARF.  I doubt that GCC is emitting these
> register numbers in its debug info anyway.

Vars living in ctr are quite common.  I've also constructed testcases
where a var lived in lr.

>  Except for AltiVec of course, and possibly ap.

ap will be eliminated to sp or fp, so shouldn't appear in DWARF debug
info (I think..).

>  The lr register is used in DWARF CFI (and
> therefore in the unwind info used for exception handling), but there
> its location is explicitly encoded in the CFI itself.
> 
> So at first sight it might be possible to fix GCC without too much
> impact.  Your concerns about GCC's splitting of cr are probably
> unnecessary since I can't imagine these ending up in the DWARF debug
> info.

Can boolean vars live in CR0..7?

I think we can define CR0..7 as 86..93.  That covers everything that gcc
might generate except for vscr, which I couldn't see defined anywhere in
the altivec PIM.  Perhaps 67 would suit?

So the following should fix dwarf register numbering for all rs6000
flavours.

#define DBX_REGISTER_NUMBER(REGNO) \
  ((REGNO) <= 63 ? (REGNO) \
   : (REGNO) == MQ_REGNO ? 100 \
   : (REGNO) == LINK_REGISTER_REGNUM ? 108 \
   : (REGNO) == COUNT_REGISTER_REGNUM ? 109 \
   : CR_REGNO_P (REGNO) ? ((REGNO) - CR0_REGNO + 86) \
   : (REGNO) == XER_REGNO ? 101 \
   : ALTIVEC_REGNO_P (REGNO) ? ((REGNO) - FIRST_ALTIVEC_REGNO + 1124) \
   : (REGNO) == VRSAVE_REGNO ? 356 \
   : (REGNO) == VSCR_REGNO ? 67 \
   : (REGNO) == SPE_ACC_REGNO ? 99 \
   : (REGNO) == SPEFSCR_REGNO ? 612 \
   : (abort (), -1))

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre