kovdan01 wrote: @atrosinenko Thanks for feedback! Addressed it in ba1154796fb6e3374f06c4bc2d5c6c16810ce2bb
> Are these module flags applicable to 32-bit ARM targets? These are indeed **not** applicable for non-AArch64, so I've moved them into a separate `if` branch (so it's not affecting ARM and Thumb). The flags represent state of `PointerAuthCalls` and `PointerAuthELFGOT`, which are only set according to corresponding cc1 flags, which are AArch64-specific. > `Module::Min` is special in that an absent flag is treated as having the > value 0 - is that correct? Yes, that's correct, but I would probably prefer avoid adding any comments with reasoning about that for other module flags - they were added by other parties when implementing different branch-protection options, and I'm just concerned that I'll mis-interpter their intentions. These flags are not related to ptrauth flags (and pauthtest) which we are interested in. > but is the `version == 0` case handled correctly? I think it was - because `version == 0` means no ptrauth features enabled, meaning no `ptrauth-calls` feature -> the `ptrauth-sign-personality` module flag set to 0. Any ABI-incompatible ptrauth configuration would anyway have `ptrauth-calls` enabled, which would make module merging broken due to `ptrauth-sign-personality` flag mismatch. However, this reasoning is complex, fragile and error-prone in terms of potential future changes. And since we are now anyway AArch64-only (not touching ARM and Thumb), just unconditionally emitting these two flags for AArch64 Linux looks fine (it does not even break any additional tests). So, I've applied your suggestion - thanks for sharing these thoughts! https://github.com/llvm/llvm-project/pull/204226 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
