Message ID | 51A37FCE.7010701@st.com |
---|---|
State | New |
Headers | show |
Christian Bruel <christian.bruel@st.com> wrote: > However I feel a little bit uncomfortable with this solution that > doesn't seem to fix the root cause. The dbx_register_number hooks is > called basically from two places : dwarf2cfi.c and dwarf2out.c. That > show different uses: either we want to refer to the hard regno when > dealing with the cfa description (whereas we want DWARF_FRAME_REGNUM, > not DBX_REGISTER_NUMBER). or we use the DBX_REGISTER_NUMBER for output > register locations. > > Since this information cannot be detected contextually, I'd like to > extend the dwarf_register_span target hook to return a dbx number or > not. This is dwarf-span-target-dbx.patch > > build tested with the configurations that failed at one time or the other: > - sh64-unknown-elf (The original sh64-elf build failure assertion in > dwarf2cfi is fixed.) > - arm-none-eabi -with-fpu=neon-vfpv4 > - powerpc-e500v2-linux-gnuspe > - x86_64-unknown-linux-gnu sanity build OK > > Is dwarf-span-target-dbx.patch OK for trunk ?. More comments ? SH portion looks fine. I've tested the patch with the top level "make -k check" also on sh4-unknown-linux-gnu with no new failures. Regards, kaz
Hello, May I have a review from the DWARF, the ARM and RS6000 maintainers for comments/approval ? http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01613.html Needed to fix the powerpc-spe bootstrap referenced in bugzilla #57389 Many Thanks Christian Christian Bruel <christian.bruel@st.com> wrote: >> However I feel a little bit uncomfortable with this solution that >> doesn't seem to fix the root cause. The dbx_register_number hooks is >> called basically from two places : dwarf2cfi.c and dwarf2out.c. That >> show different uses: either we want to refer to the hard regno when >> dealing with the cfa description (whereas we want DWARF_FRAME_REGNUM, >> not DBX_REGISTER_NUMBER). or we use the DBX_REGISTER_NUMBER for output >> register locations. >> >> Since this information cannot be detected contextually, I'd like to >> extend the dwarf_register_span target hook to return a dbx number or >> not. This is dwarf-span-target-dbx.patch >> >> build tested with the configurations that failed at one time or the other: >> - sh64-unknown-elf (The original sh64-elf build failure assertion in >> dwarf2cfi is fixed.) >> - arm-none-eabi -with-fpu=neon-vfpv4 >> - powerpc-e500v2-linux-gnuspe >> - x86_64-unknown-linux-gnu sanity build OK >> >> Is dwarf-span-target-dbx.patch OK for trunk ?. More comments ?
2013-05-23 Christian Bruel <christian.bruel@st.com> PR debug/57389 * dwarf2out.c (multiple_reg_loc_descriptor): Use DBX_REGISTER_NUMBER instead of dbx_reg_number. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 199354) +++ gcc/dwarf2out.c (working copy) @@ -10660,8 +10660,11 @@ multiple_reg_loc_descriptor (rtx rtl, rtx regs, { dw_loc_descr_ref t; - t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), + /* Cannot use dbx_reg_number here because regno could be out of the hard-reg + range and not handled by DBX_REGISTER_NUMBER. See rs6000.h. */ + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (REGNO (XVECEXP (regs, 0, i))), VAR_INIT_STATUS_INITIALIZED); + add_loc_descr (&loc_result, t); add_loc_descr_op_piece (&loc_result, size); }