Christian Bruel <christian.br...@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

Reply via email to