Don't know if it got lost or I commented this on another PR, but it should be possible for both the builder and the codegen context to get this info from the session they store.

View changes since the review

While you are right that PointerAuthSchema can be accessed through the session from both places, it is unfortunately a bit more complicated than that.

The key point is that the only place the schema is actually used is in maybe_sign_fn_ptr. That function effectively “consumes” the schema, and it is only a helper for get_fn_addr.

However, at the point where we obtain the function address, we have already lost the contextual information about which signing schema should be used. Note that (for now) there are two schemas defined in the session:

• init/fini
• default function pointer

As a result, it is up to the callers of get_fn_addr to provide the correct schema. The complication is that the information about whether a value will be emitted into init/fini arrays is only known at const_alloc_to_llvm time, which then calls into the scalar-to-backend routine (whose signature had to be also extended).

As a side note, the current implementation is a simplification. We deliberately assume only two schema choices: init/fini or default function pointer. Both are provided as a constant snapshot in the session. In reality, it should be possible for the schema to change throughout the compilation pipeline, which means we will likely need to move away from relying on the session as the source of truth. This is reflected in my WIP PR that you commented on.

Should this be a target modifier?

View changes since the review

I wasn't aware of target_modifiers before, but after reading the docs, I'd say yes. I don't think it makes that much of a difference just now, as the mismatches will always be cough by lld. You'd get something along the lines of:

   = note: ld.lld: error: incompatible values of AArch64 PAuth core info found
           platform:
           >>> /opt/llvm-pauth/lib/clang/23/lib/aarch64-unknown-linux-pauthtest/clang_rt.crtbegin.o: 0x0000000010000002
           >>> /home/jakub/Work/AccessSoftek/rust/build/aarch64-unknown-linux-gnu/test/ui/target_modifiers/incompatible_pauth/auxiliary/pauth.pauth.13435d650a747a4e-cgu.0.rcgu.o: 0x0000000010000002
           version:
           >>> /opt/llvm-pauth/lib/clang/23/lib/aarch64-unknown-linux-pauthtest/clang_rt.crtbegin.o: 0x00000000000006ff
           >>> /home/jakub/Work/AccessSoftek/rust/build/aarch64-unknown-linux-gnu/test/ui/target_modifiers/incompatible_pauth/auxiliary/pauth.pauth.13435d650a747a4e-cgu.0.rcgu.o: 0x000000000000063f
           clang: error: linker command failed with exit code 1 (use -v to see invocation)

However, having it explicit, at Rust level, before it hits the linker sounds like a clear win.

Pretty cool feature that.

I've added it in: 1c82b8f

Maybe return the Option<_> here and use is_some() at the callers that need it, then you can use this in a bunch more places where the value is used too, like in the ssa/mir/* changes.

View changes since the review

Good idea, done.

You can wrap this in // tidy-alphabetical-start and // tidy-alphabetical-end` comments if you want the ordering to stay enforced

View changes since the review

Nice, done.

I think the options make sense as currently proposed - I don't know that we'd want so many different options like Clang does, and if we don't want that then Clang's names aren't great.

Agreed that question should be part of a tracking issue.