Re: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit ices@dwf_regno

["Maciej W. Rozycki" <macro@codesourcery.com>]

Ulrich,

> > While emitting the location descriptors of multiple registers (SPE high/low
> > part) individually, the GCC hard register number is converted in to DWARF
> > register number using "dbx_reg_number" [Statement "A",  "B" & "C" below].
> 
> > But statement "C" macro "DBX_REGISTER_NUMBER" gets undefined by statement
> > "D" hence the GCC hard register number gets emitted in the debug info
> > instead of DWARF register number.  Previously, without this patch for SPE
> > high registers the GCC hard register number was same as the DWARF register
> > number (1200 onwards), hence we didn't see this issue.
> > 
> > Removing statement "D"  from "sysv4.h" file so as to generate expected
> > DWARF register number does work, but will there be any side effects?
> 
> Ah, I had completely forgotten about this issue, sorry ...
> 
> The problem with DBX_REGISTER_NUMBER is actually described in detail here:
> https://gcc.gnu.org/ml/gcc-patches/2012-11/msg02136.html
> 
> At the time, we decided to not remove the #undef DBX_REGISTER_NUMBER to
> avoid compatibility issues, but use GCC internal numbers in .debug_frame
> and .debug_info on Linux (option (3) in the above mail).  However, this
> was never actually implemented.
> 
> Looking at the current status, there are three groups of rs6000 targets:
> 
> - Some use the DBX_REGISTER_NUMBER definition from rs6000.h:
>   These are only AIX and Darwin.
> 
> - Some provide their own definition of DBX_REGISTER_NUMBER after the rs6000.h
>   one was undefined by sysv4.h:
>   These are FreeBSD, NetBSD, and Lynx.
> 
> - All other targets do not have DBX_REGISTER_NUMBER because it is undefined
>   by sysv4.h, and therefore using GCC internal register numbers:
>   These are Linux, rtems, vxworks, and all ELF/EABI targets.
> 
> 
> The following patch tries to remove the unfortunate confusion about undefining
> and redefining DBX_REGISTER_NUMBER, while keeping the behavior on all targets
> unchanged with the following two exceptions:
> - fix the SPE problem by always translating high register numbers
> - implement option (3) above by not replacing CR2 with CR in .debug_frame
>   on targets that do not use the standard DWARF register numbering
> 
> The way this works is to have a common, simple implementation of
> DBX_REGISTER_NUMBER and DWARF2_FRAME_REG_OUT for all targets that just
> calls to the rs6000_dbx_register_number routine, passing an extra format
> argument that decides whether the register number is to be used for
> .debug_info, .debug_frame, or .eh_frame.   In order to ensure
> rs6000_dbx_register_number always gets a GCC internal number as input,
> DWARF_FRAME_REGNUM has to be again defined as identity map.
> 
> All the logic to decide debug register numbers is now contained in that
> single place.  However, in order to maintain current behavior, we still
> have to distinguish between platforms that want to use the standard
> DWARF register numbering scheme, and those that use GCC internal numbers.
> This is now simply done by having the former provide a new define
> RS6000_USE_DWARF_NUMBERING in a target header file.
> 
> Tested on powerpc64le-linux and powerpc64-linux.
> 
> Rohit, could you verify whether this fixes the SPE problem?

 Thanks for your work, I have applied your change to my 4.9 setup, rebuilt 
the compiler and smoke-tested it with gdb.base/store.exp and my e500v2 
multilib only; powerpc-linux-gnu target.  Unfortunately your patch hasn't 
changed anything, the same failures remain.

 Just to be sure I haven't missed anything I reverted your change and 
Rohit's one as well, rebuilt the compiler and rerun this testing and this 
time all failures were gone.  So it looks like your fix didn't completely 
cover the damage Rohit's change caused. :(

  Maciej