Ah! Yes, I see it now. Thanks and sorry for the noise!

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).

In D80791#2120503, @nickdesaulniers wrote:

Might someone wish to disable PAC/BTI on an individual function, while having it on for the rest? I guess that would mean you can't call that function indirectly?

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.

In D75225#1896066, @MaskRay wrote:

In D75225#1895813, @kees wrote:

.text.* -> .text

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.

I think the description is correct. I have a line // If a SECTIONS command is not specified in the code block.

Here is GNU ld's internal linker script:

.text           :
{
  *(.text.unlikely .text.*_unlikely .text.unlikely.*)
  *(.text.exit .text.exit.*)
  *(.text.startup .text.startup.*)
  *(.text.hot .text.hot.*)
  *(.text .stub .text.* .gnu.linkonce.t.*)
  /* .gnu.warning sections are handled specially by elf32.em.  */
  *(.gnu.warning)
}

(As you can see, -z keep-text-section-prefix does less than what GNU ld does. One issue with GNU ld's internal linker script is that -ffunction-sections (typical when building a libc) will cause the function exit to be reordered before others...)

Hi! What's the state of this change? Do you need help committing this?

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.

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:

Thank you! I can confirm this fixes the problems I saw building the Linux kernel with CONFIG_UBSAN=y.

Thank you for the quick fix! I can confirm my builds with --string-debug work now. :)

For latest version see https://reviews.llvm.org/D64838

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:

Nick points out that "REQUIRES: x86-registered-target" is likely not needed.

Rebasing to monorepo...

Rebased to latest LLVM

I can confirm this fixes the Linux kernel relocation visibility problem I saw. Thank you!

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?)

In D53765#1386975, @kees wrote:

I found a weird mis-compilation bug. Not sure if in LLVM or Clang half. Details here: https://reviews.llvm.org/D56571#1386973

In D56571#1386973, @kees wrote:

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).

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).