Re: Incorrect DWARF-2 register numbers on PPC64?

Re: Incorrect DWARF-2 register numbers on PPC64?

[David Edelsohn]

>>>>> Andrew Cagney writes:

> Argh!  Someone teach GCC about the PPC64 DWARF register numbering
> please!  Before it is too late!  Now it is using the PPC32 LR register
> number, which just happens to be the PPC64 FPSCR register.

	The 32-bit PowerPC System V ABI defines DWARF Register Number
Mapping that does not appear to be implemented in GCC or GDB.  This issue
probably requires more thought and discussion about whether PPC64 should
be compatible with PPC32 or PPC64 should be compliant with the ABI or both
PPC32 and PPC64 should be compliant with the ABI.

David

Re: Incorrect DWARF-2 register numbers on PPC64?

[Mark Kettenis]

   Date: Thu, 18 Dec 2003 17:58:42 -0500
   From: David Edelsohn <dje@watson.ibm.com>

   >>>>> Andrew Cagney writes:

   > Argh!  Someone teach GCC about the PPC64 DWARF register numbering
   > please!  Before it is too late!  Now it is using the PPC32 LR register
   > number, which just happens to be the PPC64 FPSCR register.

	   The 32-bit PowerPC System V ABI defines DWARF Register Number
   Mapping that does not appear to be implemented in GCC or GDB.  This issue
   probably requires more thought and discussion about whether PPC64 should
   be compatible with PPC32 or PPC64 should be compliant with the ABI or both
   PPC32 and PPC64 should be compliant with the ABI.

Ah, You're right.  I should have looked a little better.  So currently
GCC uses the same mapping for DWARF as it does for stabs.  Seems like
there is a problem with GDB; we do some remapping for stabs (see
rs6000-tdep.c:rs6000_stab_reg_to_regnum), but don't remap for DWARF.
We probably should at least fix that until things are cleared up.

Personally I find it a bit awkward to use a non-standard register
mapping if there is a mapping defined in the ABI, so I'm in favour of
using the mapping defined in the System V ABI.  I don't know if this
is possible though, since changing the mapping might break exception
handling[1].

Mark

[1] From casual inspection this doesn't seem to be the case.  The
   general purpose registers will still be mapped in the same way, and
   the return address column is encoded in the debug info itself.

Re: Incorrect DWARF-2 register numbers on PPC64?

[Andrew Cagney]

>    Date: Thu, 18 Dec 2003 17:58:42 -0500
>    From: David Edelsohn <dje@watson.ibm.com>
> 
>    >>>>> Andrew Cagney writes:
> 
>    > Argh!  Someone teach GCC about the PPC64 DWARF register numbering
>    > please!  Before it is too late!  Now it is using the PPC32 LR register
>    > number, which just happens to be the PPC64 FPSCR register.
> 
> 	   The 32-bit PowerPC System V ABI defines DWARF Register Number
>    Mapping that does not appear to be implemented in GCC or GDB.  This issue
>    probably requires more thought and discussion about whether PPC64 should
>    be compatible with PPC32 or PPC64 should be compliant with the ABI or both
>    PPC32 and PPC64 should be compliant with the ABI.


> Ah, You're right.  I should have looked a little better.  So currently
> GCC uses the same mapping for DWARF as it does for stabs.  Seems like
> there is a problem with GDB; we do some remapping for stabs (see
> rs6000-tdep.c:rs6000_stab_reg_to_regnum), but don't remap for DWARF.
> We probably should at least fix that until things are cleared up.

I'd ignore GDB here.  I think GCC, for the 64-bit SvR4 PPC ABI, should 
use the correct numbers.  If that means GDB tweaks, so be it.

> Personally I find it a bit awkward to use a non-standard register
> mapping if there is a mapping defined in the ABI, so I'm in favour of
> using the mapping defined in the System V ABI.  I don't know if this
> is possible though, since changing the mapping might break exception
> handling[1].
> 
> Mark
> 
> [1] From casual inspection this doesn't seem to be the case.  The
>    general purpose registers will still be mapped in the same way, and
>    the return address column is encoded in the debug info itself.
> 

Re: Incorrect DWARF-2 register numbers on PPC64?

[Geoff Keating]

> Date: Fri, 02 Jan 2004 11:46:33 -0500
> From: Andrew Cagney <cagney@gnu.org>

> I'd ignore GDB here.  I think GCC, for the 64-bit SvR4 PPC ABI, should 
> use the correct numbers.  If that means GDB tweaks, so be it.

I agree with this.  I'd even agree with changing the 32-bit numbering
to be more correct.  As I said elsewhere, there may be trouble with
exception handling, but even then I'd support changing the numbers of
registers that aren't caller-saved, to make GCC as correct as
possible.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

This patch corrects DWARF debug info register numbering for PPC targets.
See http://gcc.gnu.org/ml/gcc/2004-01/msg00025.html for some background.

I've also made a small fix to DWARF_REG_TO_UNWIND_COLUMN which
incorrectly hardcoded an unwinder array index, and removed the confused
FIXME.  See the new comment.

	* config/rs6000/rs6000.c (rs6000_dbx_register_number): New function.
	* config/rs6000/rs6000-protos.h (rs6000_dbx_register_number): Declare.
	* config/rs6000/rs6000.h (DWARF_FRAME_REGNUM): Define.
	(DWARF_REG_TO_UNWIND_COLUMN): Correct column adjustment and comment.
	* config/rs6000/sysv4.h (DBX_REGISTER_NUMBER): Define.

Bootstrapped powerpc-linux, no regressions.

Index: gcc/config/rs6000/rs6000-protos.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000-protos.h,v
retrieving revision 1.68
diff -u -p -r1.68 rs6000-protos.h
--- gcc/config/rs6000/rs6000-protos.h	9 Dec 2003 01:57:45 -0000	1.68
+++ gcc/config/rs6000/rs6000-protos.h	6 Jan 2004 14:41:35 -0000
@@ -186,6 +186,7 @@ extern int uses_TOC (void);
 extern void rs6000_emit_prologue (void);
 extern void rs6000_emit_load_toc_table (int);
 extern void rs6000_aix_emit_builtin_unwind_init (void);
+extern unsigned int rs6000_dbx_register_number (unsigned int);
 extern void rs6000_emit_epilogue (int);
 extern void rs6000_emit_eh_reg_restore (rtx, rtx);
 extern const char * output_isel (rtx *);
Index: gcc/config/rs6000/rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.565
diff -u -p -r1.565 rs6000.c
--- gcc/config/rs6000/rs6000.c	31 Dec 2003 00:25:51 -0000	1.565
+++ gcc/config/rs6000/rs6000.c	6 Jan 2004 14:41:41 -0000
@@ -15763,4 +15763,39 @@ rs6000_dwarf_register_span (rtx reg)
 				   gen_rtx_REG (SImode, regno + 1200)));
 }
 
+/* Map internal gcc register numbers to DWARF2 register numbers.  */
+
+unsigned int
+rs6000_dbx_register_number (unsigned int regno)
+{
+  if (regno <= 63 || write_symbols != DWARF2_DEBUG)
+    return regno;
+  if (regno == MQ_REGNO)
+    return 100;
+  if (regno == LINK_REGISTER_REGNUM)
+    return 108;
+  if (regno == COUNT_REGISTER_REGNUM)
+    return 109;
+  if (CR_REGNO_P (regno))
+    return regno - CR0_REGNO + 86;
+  if (regno == XER_REGNO)
+    return 101;
+  if (ALTIVEC_REGNO_P (regno))
+    return regno - FIRST_ALTIVEC_REGNO + 1124;
+  if (regno == VRSAVE_REGNO)
+    return 356;
+  if (regno == VSCR_REGNO)
+    return 67;
+  if (regno == SPE_ACC_REGNO)
+    return 99;
+  if (regno == SPEFSCR_REGNO)
+    return 612;
+  /* SPE high reg number.  We get these values of regno from
+     rs6000_dwarf_register_span.  */
+  if (regno >= 1200 && regno < 1232)
+    return regno;
+
+  abort ();
+}
+
 #include "gt-rs6000.h"
Index: gcc/config/rs6000/rs6000.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.h,v
retrieving revision 1.303
diff -u -p -r1.303 rs6000.h
--- gcc/config/rs6000/rs6000.h	31 Dec 2003 00:25:51 -0000	1.303
+++ gcc/config/rs6000/rs6000.h	6 Jan 2004 15:09:42 -0000
@@ -811,19 +811,27 @@ extern enum rs6000_nop_insertion rs6000_
 /* This must be included for pre gcc 3.0 glibc compatibility.  */
 #define PRE_GCC3_DWARF_FRAME_REGISTERS 77
 
-/* Add 32 dwarf columns for synthetic SPE registers.  The SPE
-   synthetic registers are 113 through 145.  */
+/* Add 32 dwarf columns for synthetic SPE registers.  */
 #define DWARF_FRAME_REGISTERS (FIRST_PSEUDO_REGISTER + 32)
 
-/* The SPE has an additional 32 synthetic registers starting at 1200.
-   We must map them here to sane values in the unwinder to avoid a
-   huge hole in the unwind tables.
+/* The SPE has an additional 32 synthetic registers, with DWARF debug
+   info numbering for these registers starting at 1200.  While eh_frame
+   register numbering need not be the same as the debug info numbering,
+   we choose to number these regs for eh_frame at 1200 too.  This allows
+   future versions of the rs6000 backend to add hard registers and
+   continue to use the gcc hard register numbering for eh_frame.  If the
+   extra SPE registers in eh_frame were numbered starting from the
+   current value of FIRST_PSEUDO_REGISTER, then if FIRST_PSEUDO_REGISTER
+   changed we'd need to introduce a mapping in DWARF_FRAME_REGNUM to
+   avoid invalidating older SPE eh_frame info.
 
-   FIXME: the AltiVec ABI has AltiVec registers being 1124-1155, and
-   the VRSAVE SPR (SPR256) assigned to register 356.  When AltiVec EH
-   is verified to be working, this macro should be changed
-   accordingly.  */
-#define DWARF_REG_TO_UNWIND_COLUMN(r) ((r) > 1200 ? ((r) - 1200 + 113) : (r))
+   We must map them here to avoid huge unwinder tables mostly consisting
+   of unused space.  */ 
+#define DWARF_REG_TO_UNWIND_COLUMN(r) \
+  ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER) : (r))
+
+/* Use gcc hard register numbering for eh_frame.  */
+#define DWARF_FRAME_REGNUM(REGNO) (REGNO)
 
 /* 1 for registers that have pervasive standard uses
    and are not available for the register allocator.
Index: gcc/config/rs6000/sysv4.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
retrieving revision 1.143
diff -u -p -r1.143 sysv4.h
--- gcc/config/rs6000/sysv4.h	29 Nov 2003 03:08:12 -0000	1.143
+++ gcc/config/rs6000/sysv4.h	6 Jan 2004 14:41:45 -0000
@@ -742,6 +742,8 @@ extern int fixuplabelno;
 /* Historically we have also supported stabs debugging.  */
 #define DBX_DEBUGGING_INFO 1
 
+#define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)
+
 #define TARGET_ENCODE_SECTION_INFO  rs6000_elf_encode_section_info
 #define TARGET_IN_SMALL_DATA_P  rs6000_elf_in_small_data_p
 #define TARGET_SECTION_TYPE_FLAGS  rs6000_elf_section_type_flags

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[David Edelsohn]

	* config/rs6000/rs6000.c (rs6000_dbx_register_number): New function.
	* config/rs6000/rs6000-protos.h (rs6000_dbx_register_number): Declare.
	* config/rs6000/rs6000.h (DWARF_FRAME_REGNUM): Define.
	(DWARF_REG_TO_UNWIND_COLUMN): Correct column adjustment and comment.
	* config/rs6000/sysv4.h (DBX_REGISTER_NUMBER): Define.

This looks okay.

	I assume that a matching GDB change will be applied as well.

Thanks, David

Re: Incorrect DWARF-2 register numbers on PPC64?

[Geoff Keating]

> Date: Wed, 7 Jan 2004 01:57:10 +1030
> From: Alan Modra <amodra@bigpond.net.au>

> This patch corrects DWARF debug info register numbering for PPC targets.
> See http://gcc.gnu.org/ml/gcc/2004-01/msg00025.html for some background.
> 
> I've also made a small fix to DWARF_REG_TO_UNWIND_COLUMN which
> incorrectly hardcoded an unwinder array index, and removed the confused
> FIXME.  See the new comment.
> 
> 	* config/rs6000/rs6000.c (rs6000_dbx_register_number): New function.
> 	* config/rs6000/rs6000-protos.h (rs6000_dbx_register_number): Declare.
> 	* config/rs6000/rs6000.h (DWARF_FRAME_REGNUM): Define.
> 	(DWARF_REG_TO_UNWIND_COLUMN): Correct column adjustment and comment.
> 	* config/rs6000/sysv4.h (DBX_REGISTER_NUMBER): Define.
> 
> Bootstrapped powerpc-linux, no regressions.

Why is DBX_REGISTER_NUMBER in sysv4.h instead of rs6000.h?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Incorrect DWARF-2 register numbers on PPC64?

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> Why is DBX_REGISTER_NUMBER in sysv4.h instead of rs6000.h?

	Because only Dwarf2 register numbering is being fixed to conform
to the ABI mapping.  The register numbering for Stabs is correct.

David

Re: Incorrect DWARF-2 register numbers on PPC64?

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> >>>>> Geoff Keating writes:
> 
> Geoff> Why is DBX_REGISTER_NUMBER in sysv4.h instead of rs6000.h?
> 
> 	Because only Dwarf2 register numbering is being fixed to conform
> to the ABI mapping.  The register numbering for Stabs is correct.

Then, doesn't this patch break stabs under ELF?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Incorrect DWARF-2 register numbers on PPC64?

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> Then, doesn't this patch break stabs under ELF?

	The patch only maps the register number for DWARF2_DEBUG:

+  if (regno <= 63 || write_symbols != DWARF2_DEBUG)
+    return regno;

However, there is no reason to waste the time computing a no-op
transformation on targets that do not have a choice of Dwarf2 debugging.

David

Re: Incorrect DWARF-2 register numbers on PPC64?

[Geoff Keating]

> Date: Tue, 06 Jan 2004 17:08:40 -0500
> From: David Edelsohn <dje@watson.ibm.com>

> >>>>> Geoff Keating writes:
> 
> Geoff> Then, doesn't this patch break stabs under ELF?
> 
> 	The patch only maps the register number for DWARF2_DEBUG:
> 
> +  if (regno <= 63 || write_symbols != DWARF2_DEBUG)
> +    return regno;
> 
> However, there is no reason to waste the time computing a no-op
> transformation on targets that do not have a choice of Dwarf2 debugging.

OK.  It'd probably be better to have this at the toplevel and an undef
for AIX, since Darwin will one day have DWARF, but that can be done
later.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

On Tue, Jan 06, 2004 at 02:34:29PM -0800, Geoff Keating wrote:
> > Date: Tue, 06 Jan 2004 17:08:40 -0500
> > From: David Edelsohn <dje@watson.ibm.com>
> 
> > >>>>> Geoff Keating writes:
> > 
> > Geoff> Then, doesn't this patch break stabs under ELF?
> > 
> > 	The patch only maps the register number for DWARF2_DEBUG:
> > 
> > +  if (regno <= 63 || write_symbols != DWARF2_DEBUG)
> > +    return regno;
> > 
> > However, there is no reason to waste the time computing a no-op
> > transformation on targets that do not have a choice of Dwarf2 debugging.
> 
> OK.  It'd probably be better to have this at the toplevel and an undef
> for AIX, since Darwin will one day have DWARF, but that can be done
> later.

I originally put the DBX_REGISTER_NUMBER define in rs6000.h, but quickly
found that was #undef'd by config/svr4.h, which is included later.  If
you want the define in rs6000.h, that can be done by either removing the
#undef in svr4.h, or including rs6000.h after svr4.h.  I've done the
work to verify that you can include rs6000.h later by adding a few
#undefs in rs6000.h, and defining SIZE_TYPE in rs6000/sysv4.h (in fact,
I wrote the patch that way in the first instance), but decided that
resulted in a much more intrusive patch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[Mark Kettenis]

   Date: Wed, 7 Jan 2004 01:57:10 +1030
   From: Alan Modra <amodra@bigpond.net.au>

   This patch corrects DWARF debug info register numbering for PPC targets.
   See http://gcc.gnu.org/ml/gcc/2004-01/msg00025.html for some background.

   I've also made a small fix to DWARF_REG_TO_UNWIND_COLUMN which
   incorrectly hardcoded an unwinder array index, and removed the confused
   FIXME.  See the new comment.

	   * config/rs6000/rs6000.c (rs6000_dbx_register_number): New function.
	   * config/rs6000/rs6000-protos.h (rs6000_dbx_register_number): Declare.
	   * config/rs6000/rs6000.h (DWARF_FRAME_REGNUM): Define.
	   (DWARF_REG_TO_UNWIND_COLUMN): Correct column adjustment and comment.
	   * config/rs6000/sysv4.h (DBX_REGISTER_NUMBER): Define.

   Bootstrapped powerpc-linux, no regressions.

   Index: gcc/config/rs6000/rs6000-protos.h
   ===================================================================
   RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000-protos.h,v
   retrieving revision 1.68
   diff -u -p -r1.68 rs6000-protos.h
   --- gcc/config/rs6000/rs6000-protos.h	9 Dec 2003 01:57:45 -0000	1.68
   +++ gcc/config/rs6000/rs6000-protos.h	6 Jan 2004 14:41:35 -0000
   @@ -186,6 +186,7 @@ extern int uses_TOC (void);
    extern void rs6000_emit_prologue (void);
    extern void rs6000_emit_load_toc_table (int);
    extern void rs6000_aix_emit_builtin_unwind_init (void);
   +extern unsigned int rs6000_dbx_register_number (unsigned int);
    extern void rs6000_emit_epilogue (int);
    extern void rs6000_emit_eh_reg_restore (rtx, rtx);
    extern const char * output_isel (rtx *);
   Index: gcc/config/rs6000/rs6000.c
   ===================================================================
   RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
   retrieving revision 1.565
   diff -u -p -r1.565 rs6000.c
   --- gcc/config/rs6000/rs6000.c	31 Dec 2003 00:25:51 -0000	1.565
   +++ gcc/config/rs6000/rs6000.c	6 Jan 2004 14:41:41 -0000
   @@ -15763,4 +15763,39 @@ rs6000_dwarf_register_span (rtx reg)
				      gen_rtx_REG (SImode, regno + 1200)));
    }

   +/* Map internal gcc register numbers to DWARF2 register numbers.  */
   +
   +unsigned int
   +rs6000_dbx_register_number (unsigned int regno)
   +{
   +  if (regno <= 63 || write_symbols != DWARF2_DEBUG)
   +    return regno;
   +  if (regno == MQ_REGNO)
   +    return 100;
   +  if (regno == LINK_REGISTER_REGNUM)
   +    return 108;
   +  if (regno == COUNT_REGISTER_REGNUM)
   +    return 109;
   +  if (CR_REGNO_P (regno))
   +    return regno - CR0_REGNO + 86;
   +  if (regno == XER_REGNO)
   +    return 101;
   +  if (ALTIVEC_REGNO_P (regno))
   +    return regno - FIRST_ALTIVEC_REGNO + 1124;
   +  if (regno == VRSAVE_REGNO)
   +    return 356;
   +  if (regno == VSCR_REGNO)
   +    return 67;
   +  if (regno == SPE_ACC_REGNO)
   +    return 99;
   +  if (regno == SPEFSCR_REGNO)
   +    return 612;
   +  /* SPE high reg number.  We get these values of regno from
   +     rs6000_dwarf_register_span.  */
   +  if (regno >= 1200 && regno < 1232)
   +    return regno;
   +
   +  abort ();
   +}
   +
    #include "gt-rs6000.h"
   Index: gcc/config/rs6000/rs6000.h
   ===================================================================
   RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.h,v
   retrieving revision 1.303
   diff -u -p -r1.303 rs6000.h
   --- gcc/config/rs6000/rs6000.h	31 Dec 2003 00:25:51 -0000	1.303
   +++ gcc/config/rs6000/rs6000.h	6 Jan 2004 15:09:42 -0000
   @@ -811,19 +811,27 @@ extern enum rs6000_nop_insertion rs6000_
    /* This must be included for pre gcc 3.0 glibc compatibility.  */
    #define PRE_GCC3_DWARF_FRAME_REGISTERS 77

   -/* Add 32 dwarf columns for synthetic SPE registers.  The SPE
   -   synthetic registers are 113 through 145.  */
   +/* Add 32 dwarf columns for synthetic SPE registers.  */
    #define DWARF_FRAME_REGISTERS (FIRST_PSEUDO_REGISTER + 32)

   -/* The SPE has an additional 32 synthetic registers starting at 1200.
   -   We must map them here to sane values in the unwinder to avoid a
   -   huge hole in the unwind tables.
   +/* The SPE has an additional 32 synthetic registers, with DWARF debug
   +   info numbering for these registers starting at 1200.  While eh_frame
   +   register numbering need not be the same as the debug info numbering,
   +   we choose to number these regs for eh_frame at 1200 too.  This allows
   +   future versions of the rs6000 backend to add hard registers and
   +   continue to use the gcc hard register numbering for eh_frame.  If the
   +   extra SPE registers in eh_frame were numbered starting from the
   +   current value of FIRST_PSEUDO_REGISTER, then if FIRST_PSEUDO_REGISTER
   +   changed we'd need to introduce a mapping in DWARF_FRAME_REGNUM to
   +   avoid invalidating older SPE eh_frame info.

   -   FIXME: the AltiVec ABI has AltiVec registers being 1124-1155, and
   -   the VRSAVE SPR (SPR256) assigned to register 356.  When AltiVec EH
   -   is verified to be working, this macro should be changed
   -   accordingly.  */
   -#define DWARF_REG_TO_UNWIND_COLUMN(r) ((r) > 1200 ? ((r) - 1200 + 113) : (r))
   +   We must map them here to avoid huge unwinder tables mostly consisting
   +   of unused space.  */ 
   +#define DWARF_REG_TO_UNWIND_COLUMN(r) \
   +  ((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER) : (r))
   +
   +/* Use gcc hard register numbering for eh_frame.  */
   +#define DWARF_FRAME_REGNUM(REGNO) (REGNO)

    /* 1 for registers that have pervasive standard uses
       and are not available for the register allocator.
   Index: gcc/config/rs6000/sysv4.h
   ===================================================================
   RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
   retrieving revision 1.143
   diff -u -p -r1.143 sysv4.h
   --- gcc/config/rs6000/sysv4.h	29 Nov 2003 03:08:12 -0000	1.143
   +++ gcc/config/rs6000/sysv4.h	6 Jan 2004 14:41:45 -0000
   @@ -742,6 +742,8 @@ extern int fixuplabelno;
    /* Historically we have also supported stabs debugging.  */
    #define DBX_DEBUGGING_INFO 1

   +#define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)
   +
    #define TARGET_ENCODE_SECTION_INFO  rs6000_elf_encode_section_info
    #define TARGET_IN_SMALL_DATA_P  rs6000_elf_in_small_data_p
    #define TARGET_SECTION_TYPE_FLAGS  rs6000_elf_section_type_flags

   -- 
   Alan Modra
   IBM OzLabs - Linux Technology Centre

Alan,

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

Mark

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

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.

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.

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

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[Andrew Cagney]

> 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?)

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

Andrew

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

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

Re: Incorrect DWARF-2 register numbers on PPC64?

[Geoff Keating]

> Date: Thu, 8 Jan 2004 11:18:49 +1030
> From: Alan Modra <amodra@bigpond.net.au>

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

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

On Wed, Jan 07, 2004 at 09:01:31PM -0800, Geoff Keating wrote:
> 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
> very difficult.

I hadn't thought of that.  This means we are stuck with the current
.eh_frame register numbering.  It should be possible to fix .debug_frame
with something like the following totally untested patch.  I'm throwing
it out to the list now for comment.

With a little more work, I can get rid of DWARF_REG_TO_UNWIND_COLUMN
by having the SPE hack generate a number suitable for .eh_frame, and
mapping up to 1200 in DBX_REGISTER_NUMBER and the new
DWARF2_FRAME_REG_OUT.  So the final patch won't increasing the number of
macros littering gcc.  :)

	  * config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define.
	  * dwraf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT.

Index: gcc/config/rs6000/sysv4.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
retrieving revision 1.144
diff -u -p -r1.144 sysv4.h
--- gcc/config/rs6000/sysv4.h	7 Jan 2004 01:21:28 -0000	1.144
+++ gcc/config/rs6000/sysv4.h	9 Jan 2004 02:24:39 -0000
@@ -744,6 +744,18 @@ extern int fixuplabelno;
 
 #define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)
 
+/* Map register numbers held in the call frame info that gcc has
+   collected using DWARF_FRAME_REGNUM to those that should be output in
+   .debug_frame and .eh_frame.  We continue to use gcc hard reg numbers
+   for .eh_frame, but use the numbers mandated by the various ABIs for
+   .debug_frame.  rs6000_emit_prologue has translated any combination of
+   CR2, CR3, CR4 saves to a save of CR2.  The actual code emitted saves
+   the whole of CR, so we map CR2_REGNO to the DWARF reg for CR.  */
+#define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH)	\
+  ((FOR_EH) ? (REGNO)				\
+   : (REGNO) == CR2_REGNO ? 64			\
+   : DBX_REGISTER_NUMBER (REGNO))
+
 #define TARGET_ENCODE_SECTION_INFO  rs6000_elf_encode_section_info
 #define TARGET_IN_SMALL_DATA_P  rs6000_elf_in_small_data_p
 #define TARGET_SECTION_TYPE_FLAGS  rs6000_elf_section_type_flags
Index: gcc/dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.471
diff -u -p -r1.471 dwarf2out.c
--- gcc/dwarf2out.c	8 Jan 2004 07:54:11 -0000	1.471
+++ gcc/dwarf2out.c	9 Jan 2004 02:24:32 -0000
@@ -1783,11 +1783,21 @@ dw_cfi_oprnd2_desc (enum dwarf_call_fram
 
 #if defined (DWARF2_DEBUGGING_INFO) || defined (DWARF2_UNWIND_INFO)
 
+/* Map register numbers held in the call frame info that gcc has
+   collected using DWARF_FRAME_REGNUM to those that should be output in
+   .debug_frame and .eh_frame.  */
+#ifndef DWARF2_FRAME_REG_OUT
+#define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) (REGNO)
+#endif
+
 /* Output a Call Frame Information opcode and its operand(s).  */
 
 static void
 output_cfi (dw_cfi_ref cfi, dw_fde_ref fde, int for_eh)
 {
+  unsigned long op1_reg;
+  op1_reg = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+
   if (cfi->dw_cfi_opc == DW_CFA_advance_loc)
     dw2_asm_output_data (1, (cfi->dw_cfi_opc
 			     | (cfi->dw_cfi_oprnd1.dw_cfi_offset & 0x3f)),
@@ -1795,17 +1805,15 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 			 cfi->dw_cfi_oprnd1.dw_cfi_offset);
   else if (cfi->dw_cfi_opc == DW_CFA_offset)
     {
-      dw2_asm_output_data (1, (cfi->dw_cfi_opc
-			       | (cfi->dw_cfi_oprnd1.dw_cfi_reg_num & 0x3f)),
+      dw2_asm_output_data (1, (cfi->dw_cfi_opc | (op1_reg & 0x3f)),
 			   "DW_CFA_offset, column 0x%lx",
-			   cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+			   op1_reg);
       dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
     }
   else if (cfi->dw_cfi_opc == DW_CFA_restore)
-    dw2_asm_output_data (1, (cfi->dw_cfi_opc
-			     | (cfi->dw_cfi_oprnd1.dw_cfi_reg_num & 0x3f)),
+    dw2_asm_output_data (1, (cfi->dw_cfi_opc | (op1_reg & 0x3f)),
 			 "DW_CFA_restore, column 0x%lx",
-			 cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+			 op1_reg);
   else
     {
       dw2_asm_output_data (1, cfi->dw_cfi_opc,
@@ -1850,15 +1858,13 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 
 	case DW_CFA_offset_extended:
 	case DW_CFA_def_cfa:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  dw2_asm_output_data_uleb128 (op1_reg, NULL);
 	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
 	  break;
 
 	case DW_CFA_offset_extended_sf:
 	case DW_CFA_def_cfa_sf:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  dw2_asm_output_data_uleb128 (op1_reg, NULL);
 	  dw2_asm_output_data_sleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
 	  break;
 
@@ -1866,15 +1872,14 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 	case DW_CFA_undefined:
 	case DW_CFA_same_value:
 	case DW_CFA_def_cfa_register:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  dw2_asm_output_data_uleb128 (op1_reg, NULL);
 	  break;
 
 	case DW_CFA_register:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_reg_num,
-				       NULL);
+	  dw2_asm_output_data_uleb128 (op1_reg, NULL);
+	  dw2_asm_output_data_uleb128
+	    (DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd2.dw_cfi_reg_num, for_eh),
+	     NULL);
 	  break;
 
 	case DW_CFA_def_cfa_offset:
@@ -1904,7 +1909,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
     }
 }
 
-/* Output the call frame information used to used to record information
+/* Output the call frame information used to record information
    that relates to calculating the frame pointer, and records the
    location of saved registers.  */
 

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

On Fri, Jan 09, 2004 at 01:04:42PM +1030, Alan Modra wrote:
> With a little more work, I can get rid of DWARF_REG_TO_UNWIND_COLUMN

No I can't.  I was forgetting that we can't change eh_frame numbers.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[Alan Modra]

On Fri, Jan 09, 2004 at 01:04:42PM +1030, Alan Modra wrote:
> This means we are stuck with the current
> .eh_frame register numbering.  It should be possible to fix .debug_frame

This version actually works..  The untested one suffered from aborts in
rs6000_dbx_register_number due to calling it on invalid values.

	* config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define.
	* dwarf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT.
	* doc/tm.texi (DWARF_FRAME_REGNUM, DWARF2_FRAME_REG_OUT): Document.

Regression testing on powerpc-linux and powerpc64-linux still in
progress.  OK for mainline assuming everything passes?

Index: gcc/config/rs6000/sysv4.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
retrieving revision 1.144
diff -u -p -r1.144 sysv4.h
--- gcc/config/rs6000/sysv4.h	7 Jan 2004 01:21:28 -0000	1.144
+++ gcc/config/rs6000/sysv4.h	9 Jan 2004 06:08:50 -0000
@@ -744,6 +744,18 @@ extern int fixuplabelno;
 
 #define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO)
 
+/* Map register numbers held in the call frame info that gcc has
+   collected using DWARF_FRAME_REGNUM to those that should be output in
+   .debug_frame and .eh_frame.  We continue to use gcc hard reg numbers
+   for .eh_frame, but use the numbers mandated by the various ABIs for
+   .debug_frame.  rs6000_emit_prologue has translated any combination of
+   CR2, CR3, CR4 saves to a save of CR2.  The actual code emitted saves
+   the whole of CR, so we map CR2_REGNO to the DWARF reg for CR.  */
+#define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH)	\
+  ((FOR_EH) ? (REGNO)				\
+   : (REGNO) == CR2_REGNO ? 64			\
+   : DBX_REGISTER_NUMBER (REGNO))
+
 #define TARGET_ENCODE_SECTION_INFO  rs6000_elf_encode_section_info
 #define TARGET_IN_SMALL_DATA_P  rs6000_elf_in_small_data_p
 #define TARGET_SECTION_TYPE_FLAGS  rs6000_elf_section_type_flags
Index: gcc/dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.471
diff -u -p -r1.471 dwarf2out.c
--- gcc/dwarf2out.c	8 Jan 2004 07:54:11 -0000	1.471
+++ gcc/dwarf2out.c	9 Jan 2004 06:08:43 -0000
@@ -1783,11 +1783,19 @@ dw_cfi_oprnd2_desc (enum dwarf_call_fram
 
 #if defined (DWARF2_DEBUGGING_INFO) || defined (DWARF2_UNWIND_INFO)
 
+/* Map register numbers held in the call frame info that gcc has
+   collected using DWARF_FRAME_REGNUM to those that should be output in
+   .debug_frame and .eh_frame.  */
+#ifndef DWARF2_FRAME_REG_OUT
+#define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) (REGNO)
+#endif
+
 /* Output a Call Frame Information opcode and its operand(s).  */
 
 static void
 output_cfi (dw_cfi_ref cfi, dw_fde_ref fde, int for_eh)
 {
+  unsigned long r;
   if (cfi->dw_cfi_opc == DW_CFA_advance_loc)
     dw2_asm_output_data (1, (cfi->dw_cfi_opc
 			     | (cfi->dw_cfi_oprnd1.dw_cfi_offset & 0x3f)),
@@ -1795,17 +1803,17 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 			 cfi->dw_cfi_oprnd1.dw_cfi_offset);
   else if (cfi->dw_cfi_opc == DW_CFA_offset)
     {
-      dw2_asm_output_data (1, (cfi->dw_cfi_opc
-			       | (cfi->dw_cfi_oprnd1.dw_cfi_reg_num & 0x3f)),
-			   "DW_CFA_offset, column 0x%lx",
-			   cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+      r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, (cfi->dw_cfi_opc | (r & 0x3f)),
+			   "DW_CFA_offset, column 0x%lx", r);
       dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
     }
   else if (cfi->dw_cfi_opc == DW_CFA_restore)
-    dw2_asm_output_data (1, (cfi->dw_cfi_opc
-			     | (cfi->dw_cfi_oprnd1.dw_cfi_reg_num & 0x3f)),
-			 "DW_CFA_restore, column 0x%lx",
-			 cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+    {
+      r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, (cfi->dw_cfi_opc | (r & 0x3f)),
+			   "DW_CFA_restore, column 0x%lx", r);
+    }
   else
     {
       dw2_asm_output_data (1, cfi->dw_cfi_opc,
@@ -1850,15 +1858,15 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 
 	case DW_CFA_offset_extended:
 	case DW_CFA_def_cfa:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+	  dw2_asm_output_data_uleb128 (r, NULL);
 	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
 	  break;
 
 	case DW_CFA_offset_extended_sf:
 	case DW_CFA_def_cfa_sf:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+	  dw2_asm_output_data_uleb128 (r, NULL);
 	  dw2_asm_output_data_sleb128 (cfi->dw_cfi_oprnd2.dw_cfi_offset, NULL);
 	  break;
 
@@ -1866,15 +1874,15 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
 	case DW_CFA_undefined:
 	case DW_CFA_same_value:
 	case DW_CFA_def_cfa_register:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
+	  r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+	  dw2_asm_output_data_uleb128 (r, NULL);
 	  break;
 
 	case DW_CFA_register:
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num,
-				       NULL);
-	  dw2_asm_output_data_uleb128 (cfi->dw_cfi_oprnd2.dw_cfi_reg_num,
-				       NULL);
+	  r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+	  dw2_asm_output_data_uleb128 (r, NULL);
+	  r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd2.dw_cfi_reg_num, for_eh);
+	  dw2_asm_output_data_uleb128 (r, NULL);
 	  break;
 
 	case DW_CFA_def_cfa_offset:
@@ -1904,7 +1912,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
     }
 }
 
-/* Output the call frame information used to used to record information
+/* Output the call frame information used to record information
    that relates to calculating the frame pointer, and records the
    location of saved registers.  */
 
Index: gcc/doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.276
diff -u -p -r1.276 tm.texi
--- gcc/doc/tm.texi	30 Dec 2003 20:27:53 -0000	1.276
+++ gcc/doc/tm.texi	9 Jan 2004 06:29:37 -0000
@@ -3289,6 +3289,26 @@ column number to use instead.
 See the PowerPC's SPE target for an example.
 @end defmac
 
+@defmac DWARF_FRAME_REGNUM (@var{regno})
+
+Define this macro if the target's representation for dwarf registers
+used in .eh_frame or .debug_frame is different from that used in other
+debug info sections.  Given a gcc hard register number, this macro
+should return the .eh_frame register number.  The default is
+@code{DBX_REGISTER_NUMBER (@var{regno})}.
+
+@end defmac
+
+@defmac DWARF2_FRAME_REG_OUT (@var{regno}, @var{for_eh})
+
+Define this macro to map register numbers held in the call frame info
+that gcc has collected using @code{DWARF_FRAME_REGNUM} to those that
+should be output in .debug_frame (@code{@var{for_eh}} is zero) and
+.eh_frame (@code{@var{for_eh}} is non-zero).  The default is to 
+return @code{@var{regno}}.
+
+@end defmac
+
 @node Elimination
 @subsection Eliminating Frame Pointer and Arg Pointer
 

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Incorrect DWARF-2 register numbers on PPC64?

[Mark Kettenis]

   Date: Fri, 9 Jan 2004 13:04:42 +1030
   From: Alan Modra <amodra@bigpond.net.au>

   On Wed, Jan 07, 2004 at 09:01:31PM -0800, Geoff Keating wrote:
   > 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
   > very difficult.

   I hadn't thought of that.  This means we are stuck with the current
   .eh_frame register numbering.

I was afraid of that :-(.  

   It should be possible to fix .debug_frame with something like the
   following totally untested patch.  I'm throwing it out to the list
   now for comment.

That way we can hope that GCC's .dwarf_frame will be compatible with
DWARF CFI generated by other compilers, which would be a great win I
think.  GDB doesn't support different register encodings for .eh_frame
and .dwarf_frame yet, but that should be fixable; we can distinguish
between the two.

Mark