On Fri, Jul 05, 2019 at 06:31:51PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 5, 2019 at 6:15 PM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Sat, Jul 06, 2019 at 12:08:59AM +0800, kbuild test robot wrote:
> > > arch/arc/built-in.o: In function `arc_pmu_device_probe':
> > > >> perf_event.c:(.text+0x99e6): undefined reference to `abort'
> > > arch/arc/built-in.o:perf_event.c:(.text+0x99e6): more undefined references to `abort' follow
> >
> > I've queued up af1be2e21203 ("ARC: handle gcc generated __builtin_trap
> > for older compiler") to hopefully resolve this now.
>
> Thanks, I remember the same problem happening in mainline now,
> and this should solve the issue.
>
> I also see that the backported patch that introduced the regression
> has succeed in getting rid of many of the warnings in 4.9.y, and kernelci
> itself does not run into the abort() issue because it has a different
> compiler version:
>
> https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.184-93-gaf13e6db0db4/
>
> All that remains now is
>
> cc1: error: '-march=r3000' requires '-mfp32'
> (.text+0x1bf20): undefined reference to `iommu_is_span_boundary'
> (.text+0x1bbd0): undefined reference to `iommu_is_span_boundary'
> warning: (SIBYTE_SWARM && SIBYTE_SENTOSA && SIBYTE_BIGSUR &&
> SWIOTLB_XEN && AMD_IOMMU) selects SWIOTLB which has unmet direct
> dependencies (CAVIUM_OCTEON_SOC || MACH_LOONGSON64 && CPU_LOONGSON3 ||
> NLM_XLP_BOARD || NLM_XLR_BOARD)
> arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but
> not used [-Wunused-function]
> drivers/clk/sunxi/clk-sun8i-bus-gates.c:85:27: warning: 'clk_parent'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/arm64/kernel/vdso.c:127:6: warning: 'memcmp' reading 4 bytes from
> a region of size 1 [-Wstringop-overflow=]
>
> The two arm specific issues are fixed with these patches
>
> 4e903450bcb9 ("clk: sunxi: fix uninitialized access")
That applies.
> dbbb08f500d6 ("arm64, vdso: Define vdso_{start,end} as array")
That one does not :(
Care to backport it? :)
Now we can start tackling the gcc9 issues... :(
thanks,
greg k-h
