On Mon, Jul 30, 2018 at 11:19 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Mon, Jul 30, 2018 at 11:09:54AM +0200, Sedat Dilek wrote: >> On Mon, Jul 30, 2018 at 10:21 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> > On Sun, Jul 29, 2018 at 08:12:00PM +0200, Sedat Dilek wrote: >> >> I was able to build a Linux v4.18-rc6 with tip.git#locking/core [1] on >> >> top of it here on Debian/buster AMD64. >> >> >> >> The patch of interest is [2]... >> >> >> >> df79ed2c0643 locking/atomics: Simplify cmpxchg() instrumentation >> >> >> >> ...and some more locking/atomics[/x86] may be interesting. >> >> >> >> I had also to apply an asm-goto fix to reduce the number of warnings >> >> when building with clang-7 (version >> >> 7.0.0-svn337957-1~exp1+0~20180725200907.1908~1.gbpcccb1b (trunk)). > >> >> The kernel does ***not boot*** on bare metal. >> > >> > Ok. Does the prior commit boot? >> >> I cannot say as I was not able to compile with clang since the commit >> 8bf705d13039 mentioned here in the subject. > >> Kees pointed me to issue #7 "__builtin_constant_p() does not work in >> deep inline functions" which is the cause for not booting. >> The issue is known as #7. >> >> My qemu-log.txt is attached for details if you want to look at. >> >> [1] https://github.com/ClangBuiltLinux/linux/issues/7 >> >> >> More details see [4] and [5] for the clang-side. >> > >> > It's not clear to me how these relate to the patch in question. AFAICT, >> > those are build-time errors, but you say that the kernel doesn't boot >> > (which implies it built). >> > >> > Are [4,5] relevant to this commit, or to the (unrelated) issue [3]? >> > >> > My patch removes the switch, so this doesn't look like the same issue. >> >> ClangBuiltLinux issue #3 "clang validates extended assembly >> constraints of dead code" is the problem on the clang-side. >> Matthias and Jan commented on the thread [1] if you want to read. >> You fixed the issue on the kernel-side, so that I could build a Linux >> v4.18-rc6 with clang-7 (trunk). >> This is a huge progress - really. >> >> [1] https://groups.google.com/forum/#!topic/kasan-dev/oMgCP37n1vw >> >> Is this a bit clearer, now? > > Yes; I had misunderstood your mail as reporting a regression resulting > from my patch, rather than an improvement. > > IIUC, commit df79ed2c0643 ("locking/atomics: Simplify cmpxchg() > instrumentation") happens to make the kernel compile with clang, when it > would not previously (since commit 8bf705d13039). > > Given that you seem to understand the remaining issue, I take it that > there is nothing that I need to do here. > > Thanks, > Mark. > What are your plans to have... 4d2b25f630c7 locking/atomics: Instrument cmpxchg_double*() f9881cc43b11 locking/atomics: Instrument xchg() df79ed2c0643 locking/atomics: Simplify cmpxchg() instrumentation 00d5551cc4ee locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation ...for example in Linux 4.18 or 4.17.y? Thanks, - Sedat -
