- User Since
- Feb 6 2019, 5:35 AM (90 w, 2 d)
Aug 28 2020
Ah! Yes, I see it now. Thanks and sorry for the noise!
Aug 27 2020
Sorry if I missed something here, but why is this marked as "Closed"? It seems like the feature has still not landed (i.e. it got reverted).
Jun 29 2020
Specifically, this appears to be a legitimate bug, found by the warnings: https://bugs.llvm.org/show_bug.cgi?id=46258
Should the per-function analysis warning actually be removed? That seems like a helpful check to catch a different form of bad behavior.
Mar 9 2020
Mar 4 2020
Hi! What's the state of this change? Do you need help committing this?
Feb 27 2020
This is not accurate: ld.bfd will keep the .text.$foo names, but place them all after the .text (it does not merge them into .text). Currently, ld.lld seems to merge them into .text. FGKASLR depends on the non-merging behavior.
Feb 25 2020
Awesome! With this and D75149 my defconfig kernel build now only shows:
On my orphan checking kernel series, I'm left with only .rela_* and .rela.* getting reported, along with:
Feb 18 2020
Thank you! I can confirm this fixes the problems I saw building the Linux kernel with CONFIG_UBSAN=y.
Feb 17 2020
Thank you for the quick fix! I can confirm my builds with --string-debug work now. :)
Aug 15 2019
For latest version see https://reviews.llvm.org/D64838
Aug 9 2019
Just FYI, I can confirm a happily running arm64 kernel with CFI enabled built with this patch series. The C wrappers aren't needed and CFI is still triggering on mismatches:
May 30 2019
Nick points out that "REQUIRES: x86-registered-target" is likely not needed.
May 22 2019
May 20 2019
Rebasing to monorepo...
May 18 2019
Rebased to latest LLVM
Apr 5 2019
I can confirm this fixes the Linux kernel relocation visibility problem I saw. Thank you!
Apr 3 2019
Should I respin to make booleans always zero extended? I can adjust the X86 code at the same time...
For the non-X86 case: https://reviews.llvm.org/D60224
For note, this is based on https://reviews.llvm.org/D60208
What other target have their own lowering code? (Or, restated, is x86 the only target not using the generic lowering code?)
Feb 6 2019
I reduced the C code to this:
I found a weird mis-compilation bug. Not sure if in LLVM or Clang half. Details here: https://reviews.llvm.org/D56571#1386973
Not sure if this is the fault of the LLVM half or the Clang half, but I'm seeing mis-compilations in the current patches (llvm ca1e713fdd4fab5273b36ba6f292a844fca4cb2d with D53765.185490 and clang 01879634f01bdbfac4636ebe03b68e85b20cd664 with D56571.185489). My earlier builds were okay (llvm b1650507d25d28a03f30626843b7b133796597b4 with D53765.183738 and clang 61738985ebe78eeff6cfae7f97543d3456bac25a with D56571.181973).