On Thu, Mar 07, 2019 at 09:42:40AM -0800, Joe Perches wrote: > On Thu, 2019-03-07 at 17:25 +0000, Russell King - ARM Linux admin wrote: > > On Thu, Mar 07, 2019 at 09:19:04AM -0800, Joe Perches wrote: > > > On Thu, 2019-03-07 at 10:14 +0100, Arnd Bergmann wrote: > > > > On 32-bit ARM, I got a link failure in futex_init() when building > > > > with clang in some random configurations: > > > > > > > > kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: > > > > R_ARM_JUMP24 against `.init.text' > > > > > > > > As far as I can tell, the problem is that a branch is over 16MB > > > > apart in those configurations, but only if it branches back to > > > > the init text. > > > > > > > > Marking the futex_detect_cmpxchg() function as noinline and > > > > not __init avoids the problem for me. > > > > > > Perhaps the __init and __exit #defines should be noinline > > > to allow discarding of the code. > > > > How does that help this case? > > It doesn't particularly. > It does help any other case that might arise.
Please describe what "any other case" you are thinking of - as already stated, your patch would have no beneficial effect for the observed issue. In fact, it _could_ do exactly the opposite. Where functions can be inlined, they may become smaller due to no need for function prologue and epilogue, and other optimisations. Forcing the compiler to avoid inlining them could result in larger code, which means a higher chance of triggering the "relocation truncated to fit" problem. The converse is also a possibility too - it all depends on the inlining behaviour of the compiler towards static functions, and the resulting size of the code. What may be right for one architecture and compiler may not be right for another. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
