Christian Bruel <[email protected]> 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