On Thu, May 23, 2019 at 3:12 PM Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: > > On 20/05/2019 20:24, Jeff Law wrote: > >> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: > >>> On 09/04/2019 16:04, Jeff Law wrote: > >>>> On 4/8/19 9:17 AM, co...@sdf.org wrote: > >>>>> Pinging again in the hope of getting the patch in, I'd like to have > >>>>> less outstanding patches :) (I have quite a few and new releases > >>>>> can become painful!) > >>>>> > >>>>> gcc/ChangeLog > >>>>> > >>>>> config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration > >>>>> config.host (arm*-*-netbsd*): Build driver-arm.o > >>>>> config/arm/netbsd-eabi.h: New file. > >>>>> config/arm/netbsd-elf.h > >>>>> config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS. > >>>>> > >>>>> libgcc/ChangeLog > >>>>> > >>>>> config.host (arm*-*-netbsdelf*): Add support for EABI configuration > >>>>> config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set. > >>>>> HOST_LIBGCC2_CFLAGS: workaround possible bug > >>>>> config/arm/t-netbsd-eabi: New file. > >>>> So we're well into stage4 which means technically it's too late for > >>>> something like this. However, given it's limited scope I won't object > >>>> if the ARM port maintainers want to go forward. Otherwise I'll queue it > >>>> for gcc-10. > >>>> > >>>> jeff > >>>> > >>> > >>> I was about to approve this (modulo removing the now obsolete > >>> FPU_DEFAULT macro), until I noticed that it also modifies the generic > >>> NetBSD code as well. I'm certainly not willing to approve that myself > >>> at this late stage, but if one of the NetBSD OS maintainers wants to > >>> step up and do so, I'll happily take the Arm back-end code as that's not > >>> a primary or secondary target. > >> So is removal of the FPUTYPE_DEFAULT stuff all that's needed for this to > >> go forward now that Jason T has chimed in? > >> > >> jeff > >> > >> > > > > Very close. I was just doing a last pass through the patch to make that > > small edit when I noticed this in config/arm/netbsd-eabi.h: > > > > > > #define SUBTARGET_EXTRA_ASM_SPEC \ > > "-matpcs ..." > > > > Why is the assembler unconditionally passed -matpcs for an eabi > > configuration? That sounds broken. > > > > R. > > > > > Looking at what GAS does with this flag, it simply causes the assembler > to create an empty .arm.atpcs debug section. On that basis, I would > expect that it's then safe (and correct) to remove this: the EABI is not > the ATPCS. >
I'm not sure if this has been asked. Do you and the other authors have a copyright assignment on file with the FSF ? I don't see any one with the email co...@sdf.org on the copyright file . I think this has been asked in terms of the vax netbsd patches. regards Ramana > R. >
