On 10/17/2016 02:02 PM, Arnd Bergmann wrote: > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote: >> +CC Arnd, Michal >> >> Hi Geert, Arnd >> >> Need some guidance here. >> >> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote: >>>> 48 error regressions: >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]': => 476 >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]': => 475 >> >> [snip...] >> >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]': => 516 >>>>> + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]': => 478 >>> arcv2/axs103_smp_defconfig >> >> >> I'm thinking how to address this correctly. >> >> This is due to the older version of compiler. The fix itself is trivial - add an >> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD >> >> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which >> gets included in build comes from Kconfig (ISA supports them or not). How do we >> tie the Makefile info into the Kconfig. >> >> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and >> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience. >> >> Or the simpler solution is that kisskb upgrades the ARC GNU compiler > > Some ideas, none of which are perfect: > > - add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses > .long with hardcoded opcodes in place of the mnemonics. > > - instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file > in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD > is not set. > > - add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if > old binutils are found. I'm tending towards this one - seems cleanest, however... @Michael can I bother you to upgrade the tools or is this absolutely must for you. > > I think someone was suggesting in the past that Kconfig could be extended > to make decisions based on the gcc version, and the same thing could > be done for binutils. Don't remember who that was though. I think a number > of awkward hacks in the kernel could be simplified if we had this. > > And >
