[RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Ulrich Weigand]

Hello,

I noticed what appears to be a long-standing bug in generating .dwarf_frame
sections with GCC on Linux on PowerPC.

It had been my understanding that .dwarf_frame is supposed to differ from
.eh_frame on PowerPC w.r.t. register numbers: .eh_frame should use GCC
internal numbers, while .dwarf_frame should use the DWARF register numbers
documented in the PowerPC ELF ABI.  However, in actual fact, .dwarf_frame
does not use the DWARF numbers; and it does not use the GCC numbers either,
but a weird mixture: it uses GCC numbers for everything except for the
condition code register, for which it uses the DWARF number (64).

Doing a bit of code archaeology, it seems this behaviour goes back to a
patch checked in by Geoff Keating just before GCC 4.2.  (And indeed in
GCC 4.1 we actually have DWARF numbers in .dwarf_frame.):

use correct DWARF register numbers on rs6000 non-ELF ports
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00766.html

This patch moves the definition of the two macros DBX_REGISTER_NUMBER
and DWARF2_FRAME_REG_OUT from rs6000/sysv4.h to rs6000/rs6000.h:

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

The intention apparently was to make Darwin use the same numbers as
Linux.  However, the actual effect was to make Darwin use the same
numbers Linux used to use before, while at the same time breaking
the numbers used by Linux.

The problem is that target macro headers were included in the
following sequence:
   rs6000/rs6000.h
   svr4.h
   rs6000/sysv4.h
and the common svr4.h header contained a line:
  #undef DBX_REGISTER_NUMBER

When DBX_REGISTER_NUMBER was defined in rs6000/sysv4.h, this didn't
matter.  But now that the definition was moved to rs6000/rs6000.h,
it was in effect undone by the #undef in svr4.h, transforming the
definition of DWARF2_FRAME_REG_OUT to be:
  #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH)   \
    ((FOR_EH) ? (REGNO)                         \
     : (REGNO) == CR2_REGNO ? 64                \       
     : (REGNO))
which explains the observed behaviour of GCC since 4.2.


Since then, a couple of changes were done to the sources, but all
preserved this behaviour.  Most notably, Joseph Myers eliminated
the common sysv4.h header, but moved the #undef to rs6000/sysv4.h
instead:

svr4.h avoidance: rs6000/powerpc
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01264.html


Also, with current GCC and binutils, .dwarf_frame is usually not
generated by GCC directly, but via .cfi_... directives interpreted
by gas.  This was implemented by a patch by Jakub Jelinek:

[PATCH] Add support for .cfi_sections - way to emit also .debug_frame from .cfi_* directives
http://sourceware.org/ml/binutils/2009-10/msg00028.html

which notes:

> On ppc this is uglified by the need to translate register numbers - as
> .eh_frame uses different numbering of registers than .debug_frame.

In the patch as posted to the mailing list, this translation is here:

  /* ppc uses different register numbers between .eh_frame and .debug_frame.
     This macro translates the .eh_frame register numbers to .debug_frame
     register numbers.  */
  #define md_reg_eh_frame_to_debug_frame(regno) \
    ((regno) == 70 ? 64	/* cr2 */					\
     : (regno) == 64 ? 100 /* mq */					\
     : (regno) == 65 ? 108 /* lr */					\
     : (regno) == 66 ? 109 /* ctr */					\
     : (regno) >= 68 && (regno) <= 75 ? (regno) + 86 - 68 /* crN */	\
     : (regno) == 76 ? 101 /* xer */					\
     : (regno) >= 77 && (regno) <= 108 ? (regno) + 1124 - 77 /* vrN */	\
     : (regno) == 109 ? 356 /* vrsave */				\
     : (regno) == 110 ? 67 /* vscr */					\
     : (regno) == 111 ? 99 /* spe_acc */				\
     : (regno) == 112 ? 612 /* spefscr */				\
     : (regno))

But in the patch as actually checked in (tc-ppc.h rev. 1.41), we have:

  /* ppc uses different register numbers between .eh_frame and .debug_frame.
     This macro translates the .eh_frame register numbers to .debug_frame
     register numbers.  */
  #define md_reg_eh_frame_to_debug_frame(regno) \
    ((regno) == 70 ? 64 /* cr2 */ : (regno))

So it seems Jakub also noticed that GCC's behaviour did not actually
followed the documented ABI, and chose to mirror the actual behaviour
in GCC instead.


However, on the GDB side, we actually expect DWARF numbers in .dwarf_frame.
There is a hack in rs6000-tdep.c:rs6000_adjust_frame_regnum that makes it
proceed at least somewhat by fixing up the LR number:

static int
rs6000_adjust_frame_regnum (struct gdbarch *gdbarch, int num, int eh_frame_p)
{
  /* GCC releases before 3.4 use GCC internal register numbering in
     .debug_frame (and .debug_info, et cetera).  The numbering is
     different from the standard SysV numbering for everything except
     for GPRs and FPRs.  We can not detect this problem in most cases
     - to get accurate debug info for variables living in lr, ctr, v0,
     et cetera, use a newer version of GCC.  But we must detect
     one important case - lr is in column 65 in .debug_frame output,
     instead of 108.

     GCC 3.4, and the "hammer" branch, have a related problem.  They
     record lr register saves in .debug_frame as 108, but still record
     the return column as 65.  We fix that up too.

     We can do this because 65 is assigned to fpsr, and GCC never
     generates debug info referring to it.  To add support for
     handwritten debug info that restores fpsr, we would need to add a
     producer version check to this.  */
  if (!eh_frame_p)
    {
      if (num == 65)
        return 108;
      else
        return num;
    }

But as the comment says, this isn't really a solution for things like
values in vector registers.  Unfortunately, "use a newer version of
GCC" isn't really quite right any more: the only versions of GCC that
ever did it correctly were 4.0 and 4.1, it would appear.


So I'm wondering where to go from here.  I guess we could:

1. Bring GCC (and gas) behaviour in compliance with the documented ABI
   by removing the #undef DBX_REGISTER_NUMBER and changing gas's
   md_reg_eh_frame_to_debug_frame to the original implementation from
   Jakub's patch.  That would make GDB work well on new files, but
   there are a large number of binaries out there where we continue
   to have the same behaviour as today ...

2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
   .dwarf_frame, except for the condition code register.  This would
   break debugging of files built with GCC 4.0 and 4.1 unless we
   want to add a special hack for that.

3. Like 2., but remove the condition code hack: simply use identical
   numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
   like other Linux platforms in that respect.

Thoughts?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[David Edelsohn]

On Mon, Nov 26, 2012 at 2:10 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:

> So I'm wondering where to go from here.  I guess we could:
>
> 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
>    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
>    md_reg_eh_frame_to_debug_frame to the original implementation from
>    Jakub's patch.  That would make GDB work well on new files, but
>    there are a large number of binaries out there where we continue
>    to have the same behaviour as today ...
>
> 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
>    .dwarf_frame, except for the condition code register.  This would
>    break debugging of files built with GCC 4.0 and 4.1 unless we
>    want to add a special hack for that.
>
> 3. Like 2., but remove the condition code hack: simply use identical
>    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
>    like other Linux platforms in that respect.
>
> Thoughts?

I vote for (3).

Thanks, David

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Mark Kettenis]

> Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 
> Hello,
> 
> I noticed what appears to be a long-standing bug in generating .dwarf_frame
> sections with GCC on Linux on PowerPC.
> 
> ...
> 
> So I'm wondering where to go from here.  I guess we could:
> 
> 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
>    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
>    md_reg_eh_frame_to_debug_frame to the original implementation from
>    Jakub's patch.  That would make GDB work well on new files, but
>    there are a large number of binaries out there where we continue
>    to have the same behaviour as today ...
> 
> 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
>    .dwarf_frame, except for the condition code register.  This would
>    break debugging of files built with GCC 4.0 and 4.1 unless we
>    want to add a special hack for that.
> 
> 3. Like 2., but remove the condition code hack: simply use identical
>    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
>    like other Linux platforms in that respect.
> 
> Thoughts?

What do other compilers (in particular XLC) do?  From a GDB standpoint
it would be a major PITA if different compilers would use different
encodings for .dwarf_frame.

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Mark Wielaard]

On Mon, 2012-11-26 at 20:10 +0100, Ulrich Weigand wrote:
> I noticed what appears to be a long-standing bug in generating .dwarf_frame
> sections with GCC on Linux on PowerPC.
> 
> It had been my understanding that .dwarf_frame is supposed to differ from
> .eh_frame on PowerPC w.r.t. register numbers: .eh_frame should use GCC
> internal numbers, while .dwarf_frame should use the DWARF register numbers
> documented in the PowerPC ELF ABI.  However, in actual fact, .dwarf_frame
> does not use the DWARF numbers; and it does not use the GCC numbers either,
> but a weird mixture: it uses GCC numbers for everything except for the
> condition code register, for which it uses the DWARF number (64).
> [...]
> Unfortunately, "use a newer version of
> GCC" isn't really quite right any more: the only versions of GCC that
> ever did it correctly were 4.0 and 4.1, it would appear.

Aha. Thanks for the investigation. I remember being very confused when
hacking on the Systemtap unwinder for ppc64. This explains it (RHEL5
derived distributions use GCC 4.1, but most others use something much
older or much newer).

> So I'm wondering where to go from here.  I guess we could:
> 
> 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
>    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
>    md_reg_eh_frame_to_debug_frame to the original implementation from
>    Jakub's patch.  That would make GDB work well on new files, but
>    there are a large number of binaries out there where we continue
>    to have the same behaviour as today ...
> 
> 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
>    .dwarf_frame, except for the condition code register.  This would
>    break debugging of files built with GCC 4.0 and 4.1 unless we
>    want to add a special hack for that.
> 
> 3. Like 2., but remove the condition code hack: simply use identical
>    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
>    like other Linux platforms in that respect.
> 
> Thoughts?

Which other unwinders are out there, that might rely on the current
numbering? The Systemtap runtime unwinder (*) currently is incomplete
(and in one case wrong since the numbering overlaps), so it doesn't
really matter much which solution you pick (we will just have to watch
out and fix things to be as consistent as possible when your change goes
through). If you do change the numbering it would be ideal if there was
a way to detect which one was in place (although it is probably hopeless
because depending on which GCC version is in use there can already be
different numberings). BTW. The reason the systemtap runtime unwinder is
a little wrong here is because on all other architectures we assume
eh_frame and debug_frame DWARF register numberings are equal, is ppc
really the only architecture for which that isn't true, or were we just
lucky?

Thanks,

Mark

(*) The Systemtap runtime unwinder has this comment that explains (or
maybe confuses things even more...):

/* These are slightly strange since they don't really use dwarf register
   mappings, but gcc internal register numbers. There is some confusion about
   the numbering see http://gcc.gnu.org/ml/gcc/2004-01/msg00025.html
   We just handle the 32 fixed point registers, mq, count and link and
   ignore status registers, floating point, vectors and special registers
   (most of which aren't available in pt_regs anyway). Also we placed nip
   last since we use that as UNW_PC register and it needs to be filled in.
   Note that we handle both the .eh_frame and .debug_frame numbering at
   the same time. There is potential overlap though. 64 maps to cr in one
   and mq in the other...
   Everything else is mapped to an invalid register number 9999. */

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Ulrich Weigand]

Mark Kettenis wrote:
> > Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > Hello,
> > 
> > I noticed what appears to be a long-standing bug in generating .dwarf_frame
> > sections with GCC on Linux on PowerPC.
> > 
> > ...
> > 
> > So I'm wondering where to go from here.  I guess we could:
> > 
> > 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
> >    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
> >    md_reg_eh_frame_to_debug_frame to the original implementation from
> >    Jakub's patch.  That would make GDB work well on new files, but
> >    there are a large number of binaries out there where we continue
> >    to have the same behaviour as today ...
> > 
> > 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
> >    .dwarf_frame, except for the condition code register.  This would
> >    break debugging of files built with GCC 4.0 and 4.1 unless we
> >    want to add a special hack for that.
> > 
> > 3. Like 2., but remove the condition code hack: simply use identical
> >    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
> >    like other Linux platforms in that respect.
> > 
> > Thoughts?
> 
> What do other compilers (in particular XLC) do?  From a GDB standpoint
> it would be a major PITA if different compilers would use different
> encodings for .dwarf_frame.

In my tests XLC (version 12.1 on Linux) seems to consistently use the
GCC register numbering in both .eh_frame and .dwarf_frame.  LLVM also
consistently uses the GCC register numbering.  Looks like this would
be another argument for variant 3 ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Ulrich Weigand]

Mark Wielaard wrote:

> Which other unwinders are out there, that might rely on the current
> numbering?

Well, runtime unwinders using .eh_frame should be fine, since this
uses (and has always used) consistently the GCC numbering.  I don't
know if there are other unwinders using .dwarf_frame ...

> The Systemtap runtime unwinder (*) currently is incomplete
> (and in one case wrong since the numbering overlaps), so it doesn't
> really matter much which solution you pick (we will just have to watch
> out and fix things to be as consistent as possible when your change goes
> through). If you do change the numbering it would be ideal if there was
> a way to detect which one was in place (although it is probably hopeless
> because depending on which GCC version is in use there can already be
> different numberings).

The change will most likely be to consistently use GCC numbering in
.dwarf_frame as well, which changes only the encoding of the condition
code register.  Since you're not using that at all in systemtap, you
shouldn't be affected.

> BTW. The reason the systemtap runtime unwinder is
> a little wrong here is because on all other architectures we assume
> eh_frame and debug_frame DWARF register numberings are equal, is ppc
> really the only architecture for which that isn't true, or were we just
> lucky?

As far as Linux goes, yes, ppc was the only architecture with a
different encoding between .eh_frame and .dwarf_frame.  The only
other such platforms I'm aware of are Darwin on 32-bit i386, and
some other operating systems on ppc (AIX, Darwin, BSD).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Ulrich Weigand]

David Edelsohn wrote:
> On Mon, Nov 26, 2012 at 2:10 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> 
> > So I'm wondering where to go from here.  I guess we could:
> >
> > 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
> >    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
> >    md_reg_eh_frame_to_debug_frame to the original implementation from
> >    Jakub's patch.  That would make GDB work well on new files, but
> >    there are a large number of binaries out there where we continue
> >    to have the same behaviour as today ...
> >
> > 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
> >    .dwarf_frame, except for the condition code register.  This would
> >    break debugging of files built with GCC 4.0 and 4.1 unless we
> >    want to add a special hack for that.
> >
> > 3. Like 2., but remove the condition code hack: simply use identical
> >    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
> >    like other Linux platforms in that respect.
> >
> > Thoughts?
> 
> I vote for (3).

I'd agree, in particular given that XLC and LLVM seem to match this
behaviour as well.

Looking into this further, it turns out that on Linux not only .debug_frame
is affected, but also .debug_info and all the other .debug_... sections.
DBX_REGISTER_NUMBER is used for register numbers in those sections too ...

This again doesn't match what GDB is expecting:  For regular debug info
(not frame info), GDB only distinguished between stabs and DWARF, and
assumes GCC numbering for stabs, and DWARF numbering for DWARF.  This
holds for any PowerPC operating system.

However, looking at GCC behaviour, we have instead GCC numbering used
in either stabs or DWARF on Linux, but DWARF numbering apparently used
in either stabs or DWARF on AIX/BSD/Darwin.

Here, comparison with other compilers is less clear.  I wasn't able to
get XLC on Linux to generate any .debug_info containing a register
number for non-GPR/FPR registers (it would always put such variables
on the stack).  The XLC on AIX I have access to is quite old and only
generates stabs; again I wasn't able to see any non-GPR register
assignments.  LLVM consistently uses the GCC numbering on all operating
systems it supports (I think that's Linux, Darwin, and FreeBSD).

As far as Linux is concerned, leaving the compilers as-is and changing
GDB to expect GCC numbering might be the best option.  Not sure about
other operating systems ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Mark Kettenis]

> Date: Tue, 27 Nov 2012 19:43:40 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 
> Mark Kettenis wrote:
> > > Date: Mon, 26 Nov 2012 20:10:06 +0100 (CET)
> > > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > > 
> > > Hello,
> > > 
> > > I noticed what appears to be a long-standing bug in generating .dwarf_frame
> > > sections with GCC on Linux on PowerPC.
> > > 
> > > ...
> > > 
> > > So I'm wondering where to go from here.  I guess we could:
> > > 
> > > 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
> > >    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
> > >    md_reg_eh_frame_to_debug_frame to the original implementation from
> > >    Jakub's patch.  That would make GDB work well on new files, but
> > >    there are a large number of binaries out there where we continue
> > >    to have the same behaviour as today ...
> > > 
> > > 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
> > >    .dwarf_frame, except for the condition code register.  This would
> > >    break debugging of files built with GCC 4.0 and 4.1 unless we
> > >    want to add a special hack for that.
> > > 
> > > 3. Like 2., but remove the condition code hack: simply use identical
> > >    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
> > >    like other Linux platforms in that respect.
> > > 
> > > Thoughts?
> > 
> > What do other compilers (in particular XLC) do?  From a GDB standpoint
> > it would be a major PITA if different compilers would use different
> > encodings for .dwarf_frame.
> 
> In my tests XLC (version 12.1 on Linux) seems to consistently use the
> GCC register numbering in both .eh_frame and .dwarf_frame.  LLVM also
> consistently uses the GCC register numbering.  Looks like this would
> be another argument for variant 3 ...

Probably.  Certainly the most practical solution.  Although I'd say
that the fact that people have been able to live with the non-matching
register numbering schemes for so many years means that variant 1
wouldn't hurt people too badly.  It's a bit of a shame that on one of
the few architectures that bothered to provide a definition of the
DWARF register numbers we wouldn't use it :(.

Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Mark Wielaard]

On Tue, 2012-11-27 at 19:49 +0100, Ulrich Weigand wrote:
> Mark Wielaard wrote:
> 
> > Which other unwinders are out there, that might rely on the current
> > numbering?
> 
> Well, runtime unwinders using .eh_frame should be fine, since this
> uses (and has always used) consistently the GCC numbering.  I don't
> know if there are other unwinders using .dwarf_frame ...

The reason systemtap hits this is that it can do unwinding of both user
and kernel space. The linux kernel doesn't include eh_frames, so we have
to fall back to .debug_frame.

> The change will most likely be to consistently use GCC numbering in
> .dwarf_frame as well, which changes only the encoding of the condition
> code register.  Since you're not using that at all in systemtap, you
> shouldn't be affected.

Yeah, we only use the unwinder currently to produce backtraces, which
are unlikely to rely on the condition code register.

> As far as Linux goes, yes, ppc was the only architecture with a
> different encoding between .eh_frame and .dwarf_frame.

In that case your option 3 seems ideal.

Thanks,

Mark

[PATCH] Remove md_reg_eh_frame_to_debug_frame on PPC (Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC)

[Ulrich Weigand]

Two years ago I wrote:

> So I'm wondering where to go from here.  I guess we could:
> 
> 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
>    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
>    md_reg_eh_frame_to_debug_frame to the original implementation from
>    Jakub's patch.  That would make GDB work well on new files, but
>    there are a large number of binaries out there where we continue
>    to have the same behaviour as today ...
> 
> 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
>    .dwarf_frame, except for the condition code register.  This would
>    break debugging of files built with GCC 4.0 and 4.1 unless we
>    want to add a special hack for that.
> 
> 3. Like 2., but remove the condition code hack: simply use identical
>    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
>    like other Linux platforms in that respect.

GCC has now been changed to implement suggestion 3 here:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00685.html

So I think we should also change GAS to match the new GCC behavior.
This simply means removing the PPC-specific definition of the macro
md_reg_eh_frame_to_debug_frame.

The attached patch implements this.  Tested on powerpc64-linux.
Would this be OK for mainline (and possibly 2.25 branch)?

Bye,
Ulrich

ChangeLog:

	* config/tc-ppc.h (md_reg_eh_frame_to_debug_frame): Do not define.

diff --git a/gas/config/tc-ppc.h b/gas/config/tc-ppc.h
index 3cd9bf1..3aecafa 100644
--- a/gas/config/tc-ppc.h
+++ b/gas/config/tc-ppc.h
@@ -267,12 +267,6 @@ extern int ppc_parse_name (const char *, struct expressionS *);
 #define md_cleanup() ppc_cleanup ()
 extern void ppc_cleanup (void);
 
-/* ppc uses different register numbers between .eh_frame and .debug_frame.
-   This macro translates the .eh_frame register numbers to .debug_frame
-   register numbers.  */
-#define md_reg_eh_frame_to_debug_frame(regno) \
-  ((regno) == 70 ? 64 /* cr2 */ : (regno))
-
 #define TARGET_USE_CFIPOP 1
 
 #define tc_cfi_frame_initial_instructions ppc_cfi_frame_initial_instructions

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: [PATCH] Remove md_reg_eh_frame_to_debug_frame on PPC (Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC)

[Alan Modra]

On Thu, Dec 11, 2014 at 09:27:30PM +0100, Ulrich Weigand wrote:
> GCC has now been changed to implement suggestion 3 here:
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00685.html
> 
> So I think we should also change GAS to match the new GCC behavior.
> This simply means removing the PPC-specific definition of the macro
> md_reg_eh_frame_to_debug_frame.
> 
> The attached patch implements this.

If I understand the gcc code correctly, it seems to me that the patch
doesn't make gas match the new gcc behaviour.  :-(

To be consistent with gcc, shouldn't this instead be something like
the following?  (It also needs another emulation file defining TE_AIX
to support aix < 5.)

diff --git a/gas/config/tc-ppc.h b/gas/config/tc-ppc.h
index 3cd9bf1..8c80e8a 100644
--- a/gas/config/tc-ppc.h
+++ b/gas/config/tc-ppc.h
@@ -267,11 +267,24 @@ extern int ppc_parse_name (const char *, struct expressionS *);
 #define md_cleanup() ppc_cleanup ()
 extern void ppc_cleanup (void);
 
+#if (defined TE_AIX5 || defined TE_AIX					\
+     || defined TE_FreeBSD || defined TE_NetBSD || defined TE_LYNX)
 /* ppc uses different register numbers between .eh_frame and .debug_frame.
    This macro translates the .eh_frame register numbers to .debug_frame
    register numbers.  */
-#define md_reg_eh_frame_to_debug_frame(regno) \
-  ((regno) == 70 ? 64 /* cr2 */ : (regno))
+#define md_reg_eh_frame_to_debug_frame(regno)				\
+  ((regno) == 70 ? 64	/* cr2 */					\
+   : (regno) == 65 ? 108 /* lr */					\
+   : (regno) == 66 ? 109 /* ctr */					\
+   : (regno) >= 68 && (regno) <= 75 ? (regno) + 86 - 68 /* crN */	\
+   : (regno) == 76 ? 101 /* xer */					\
+   : (regno) >= 77 && (regno) <= 108 ? (regno) + 1124 - 77 /* vrN */	\
+   : (regno) == 109 ? 356 /* vrsave */					\
+   : (regno) == 110 ? 67 /* vscr */					\
+   : (regno) == 111 ? 99 /* spe_acc */					\
+   : (regno) == 112 ? 612 /* spefscr */					\
+   : (regno))
+#endif
 
 #define TARGET_USE_CFIPOP 1
 

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Remove md_reg_eh_frame_to_debug_frame on PPC (Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC)

[Ulrich Weigand]

Alan Modra wrote:
> On Thu, Dec 11, 2014 at 09:27:30PM +0100, Ulrich Weigand wrote:
> > GCC has now been changed to implement suggestion 3 here:
> > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00685.html
> > 
> > So I think we should also change GAS to match the new GCC behavior.
> > This simply means removing the PPC-specific definition of the macro
> > md_reg_eh_frame_to_debug_frame.
> > 
> > The attached patch implements this.
> 
> If I understand the gcc code correctly, it seems to me that the patch
> doesn't make gas match the new gcc behaviour.  :-(
> 
> To be consistent with gcc, shouldn't this instead be something like
> the following?  (It also needs another emulation file defining TE_AIX
> to support aix < 5.)

Ah, you're right -- I hadn't considered non-Linux platforms (but then,
they weren't supported previously either ...).   Not sure if all of these
platforms actually use gas to create .debug_frame sections, but it would
certainly be better to be compatible to gcc if they do.

> diff --git a/gas/config/tc-ppc.h b/gas/config/tc-ppc.h
> index 3cd9bf1..8c80e8a 100644
> --- a/gas/config/tc-ppc.h
> +++ b/gas/config/tc-ppc.h
> @@ -267,11 +267,24 @@ extern int ppc_parse_name (const char *, struct expressionS *);
>  #define md_cleanup() ppc_cleanup ()
>  extern void ppc_cleanup (void);
>  
> +#if (defined TE_AIX5 || defined TE_AIX					\
> +     || defined TE_FreeBSD || defined TE_NetBSD || defined TE_LYNX)
>  /* ppc uses different register numbers between .eh_frame and .debug_frame.
>     This macro translates the .eh_frame register numbers to .debug_frame
>     register numbers.  */
> -#define md_reg_eh_frame_to_debug_frame(regno) \
> -  ((regno) == 70 ? 64 /* cr2 */ : (regno))
> +#define md_reg_eh_frame_to_debug_frame(regno)				\
> +  ((regno) == 70 ? 64	/* cr2 */					\
> +   : (regno) == 65 ? 108 /* lr */					\
> +   : (regno) == 66 ? 109 /* ctr */					\
> +   : (regno) >= 68 && (regno) <= 75 ? (regno) + 86 - 68 /* crN */	\
> +   : (regno) == 76 ? 101 /* xer */					\
> +   : (regno) >= 77 && (regno) <= 108 ? (regno) + 1124 - 77 /* vrN */	\
> +   : (regno) == 109 ? 356 /* vrsave */					\
> +   : (regno) == 110 ? 67 /* vscr */					\
> +   : (regno) == 111 ? 99 /* spe_acc */					\
> +   : (regno) == 112 ? 612 /* spefscr */					\
> +   : (regno))
> +#endif

This looks good to me.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: [PATCH] Remove md_reg_eh_frame_to_debug_frame on PPC (Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC)

[Alan Modra]

On Fri, Dec 12, 2014 at 12:43:39PM +0100, Ulrich Weigand wrote:
> Alan Modra wrote:
> > On Thu, Dec 11, 2014 at 09:27:30PM +0100, Ulrich Weigand wrote:
> > > GCC has now been changed to implement suggestion 3 here:
> > > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00685.html
> > > 
> > > So I think we should also change GAS to match the new GCC behavior.
> > > This simply means removing the PPC-specific definition of the macro
> > > md_reg_eh_frame_to_debug_frame.
> > > 
> > > The attached patch implements this.
> > 
> > If I understand the gcc code correctly, it seems to me that the patch
> > doesn't make gas match the new gcc behaviour.  :-(
> > 
> > To be consistent with gcc, shouldn't this instead be something like
> > the following?  (It also needs another emulation file defining TE_AIX
> > to support aix < 5.)
> 
> Ah, you're right -- I hadn't considered non-Linux platforms (but then,
> they weren't supported previously either ...).   Not sure if all of these
> platforms actually use gas to create .debug_frame sections, but it would
> certainly be better to be compatible to gcc if they do.

gcc may not use gas .cfi directives to create .debug_frame but it is
possible to do so in assembly.  I'm committing the following.

This makes gas .cfi output to .debug_frame match register numbering
emitted by gcc.  md_reg_eh_frame_to_debug_frame follows the ABI,
targets not using it, notably Linux, don't.

	* config/tc-ppc.h (md_reg_eh_frame_to_debug_frame): Match current
	gcc behaviour.
	* config/te-aix.h: New file.
	* configure.tgt: Use em=aix for powerpc-aix.

diff --git a/gas/config/tc-ppc.h b/gas/config/tc-ppc.h
index 3cd9bf1..d9551c1 100644
--- a/gas/config/tc-ppc.h
+++ b/gas/config/tc-ppc.h
@@ -267,11 +267,24 @@ extern int ppc_parse_name (const char *, struct expressionS *);
 #define md_cleanup() ppc_cleanup ()
 extern void ppc_cleanup (void);
 
+#if (defined TE_AIX5 || defined TE_AIX					\
+     || defined TE_FreeBSD || defined TE_NetBSD || defined TE_LYNX)
 /* ppc uses different register numbers between .eh_frame and .debug_frame.
    This macro translates the .eh_frame register numbers to .debug_frame
    register numbers.  */
-#define md_reg_eh_frame_to_debug_frame(regno) \
-  ((regno) == 70 ? 64 /* cr2 */ : (regno))
+#define md_reg_eh_frame_to_debug_frame(regno)				\
+  ((regno) == 70 ? 64	/* cr2 */					\
+   : (regno) == 65 ? 108 /* lr */					\
+   : (regno) == 66 ? 109 /* ctr */					\
+   : (regno) >= 68 && (regno) <= 75 ? (regno) + 86 - 68 /* crN */	\
+   : (regno) == 76 ? 101 /* xer */					\
+   : (regno) >= 77 && (regno) <= 108 ? (regno) + 1124 - 77 /* vrN */	\
+   : (regno) == 109 ? 356 /* vrsave */					\
+   : (regno) == 110 ? 67 /* vscr */					\
+   : (regno) == 111 ? 99 /* spe_acc */					\
+   : (regno) == 112 ? 612 /* spefscr */					\
+   : (regno))
+#endif
 
 #define TARGET_USE_CFIPOP 1
 
diff --git a/gas/config/te-aix.h b/gas/config/te-aix.h
new file mode 100644
index 0000000..b0da4fb
--- /dev/null
+++ b/gas/config/te-aix.h
@@ -0,0 +1,22 @@
+/* Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GAS, the GNU Assembler.
+
+   GAS is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 3,
+   or (at your option) any later version.
+
+   GAS is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+   the GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GAS; see the file COPYING.  If not, write to the Free
+   Software Foundation, 51 Franklin Street - Fifth Floor, Boston, MA
+   02110-1301, USA.  */
+
+#define TE_AIX
+
+#include "obj-format.h"
diff --git a/gas/configure.tgt b/gas/configure.tgt
index 853988a..0e44880 100644
--- a/gas/configure.tgt
+++ b/gas/configure.tgt
@@ -373,7 +373,7 @@ case ${generic_target} in
   ppc-*-winnt*)				fmt=coff em=pe ;;
   ppc-*-aix5.[01])			fmt=coff em=aix5 ;;
   ppc-*-aix[5-9].*)			fmt=coff em=aix5 ;;
-  ppc-*-aix*)				fmt=coff ;;
+  ppc-*-aix*)				fmt=coff em=aix ;;
   ppc-*-beos*)				fmt=coff ;;
   ppc-*-*n*bsd* | ppc-*-elf*)		fmt=elf ;;
   ppc-*-eabi* | ppc-*-sysv4*)		fmt=elf ;;

-- 
Alan Modra
Australia Development Lab, IBM