On Wed, Oct 8, 2014 at 2:09 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > rohitarulraj wrote: > >> I was able to narrow down the issue. > [snip] >> 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? > > David, does this approach look reasonable to you?
This seems like the best solution. Thanks for untangling this. - David
