On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> wrote: > > For the record, this is an example of why I think backporting those > > clang enablement patches is a bad idea. > > There's always a risk involved with backports of any kind; more CI > coverage can help us mitigate some of these risks in an automated > fashion before we get user reports like this. I meet with the > KernelCI folks weekly, so I'll double check on the coverage of the > stable tree's branches. The 0day folks are also very responsive and > I've spoken with them a few times, so I'll try to get to the bottom of > why this wasn't reported by either of those. > > Also, these patches help keep Android, CrOS, and Google internal > production kernels closer to their upstream sources. > > > We can't actually build those > > kernels with clang, can we? So what is the point? </grumpy> > > Here's last night's build: > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > If you are saying that plain upstream 4.9-stable defconfig can be built with Clang, then I am pleasantly surprised. > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > built with Clang. I think this number will grow at least one order of > magnitude imminently. > I know that (since you keep reminding me :-)), but obviously, Google does not care about changes that regress GCC support. > > Alternatively, we can just revert this patch from 4.9 > > That would break at least the above devices next time Android and CrOS > pulled from stable. > > > It would be helpful to get a relocation dump (objdump -r) of > > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to > > prevent GCC from emitting it as a PIC reference requiring a GOT. > > Sounds like the best way forward, as well as having more info on which > config/toolchain reliably reproduces the issue. Let me know once you can reproduce it, I will have a look as well.
