Mach-O check for improperly nested .cfi_* regions doesn't take .alt_entry into account

[filipnavara]

This is a similar case to #82261 where an exception was added to for .alt_entry to the non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs check.

Commit 0b06727 introduced the invalid CFI advance_loc expression error with seemingly similar intentions.

Now, let's look at this example code:

.section __TEXT,__text
.globl _foo
_foo:
  .cfi_startproc
  sub sp, sp, 8
  .cfi_adjust_cfa_offset 8
  .alt_entry _bar
_bar:
  add sp, sp, 8
  .cfi_adjust_cfa_offset -8
  ret
  .cfi_endproc

My assumption is that .alt_entry should be exempt from the "advance_loc" check just like it's exempt from the "cfi_startproc/cfi_endproc" check. Feel free to correct my expectations if they are wrong.

As for the real world use case, this came up as an issue in the Microsoft .NET Runtime. There are some functions written in assembly that may trigger an AV at specified code points. The intention of the labels inside those functions is to mark the address of the instruction that triggers the AV so a signal handler can process it appropriately. It's not a callable entrypoint, just a way to get address of a given instruction.

[filipnavara]

/cc @MaskRay since you originally authored the commit.
/cc @jroelofs for validation on what is the intended behavior.

[jroelofs]

The intent, AFAIU, is to allow this, but I'll defer to Maskray on the advance_loc bit.

The problematic case is when you have multiple independent functions that span a single cfi region when .subsections_via_symbols is present: that can cause some relocations to be manifest that can't be materialized, since they're relative to two independent subsections. .alt_entry's don't have that problem.

[MaskRay]

The intent, AFAIU, is to allow this, but I'll defer to Maskray on the advance_loc bit.

The problematic case is when you have multiple independent functions that span a single cfi region when .subsections_via_symbols is present: that can cause some relocations to be manifest that can't be materialized, since they're relative to two independent subsections. .alt_entry's don't have that problem.

I agree that the example should be supported. The bug resides in our setAtom code in MCMachOStreamer::finishImpl. I am writing a patch.

[MaskRay]

The intent, AFAIU, is to allow this, but I'll defer to Maskray on the advance_loc bit.
The problematic case is when you have multiple independent functions that span a single cfi region when .subsections_via_symbols is present: that can cause some relocations to be manifest that can't be materialized, since they're relative to two independent subsections. .alt_entry's don't have that problem.

I agree that the example should be supported. The bug resides in our setAtom code in MCMachOStreamer::finishImpl. I am writing a patch.

Patch: #97479

[filipnavara]

Thanks!