================
@@ -704,8 +704,10 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase
&isec,
uint64_t offsetInSec, Symbol &sym, int64_t addend,
RelExpr expr, RelType type) {
Partition &part = isec.getPartition(ctx);
+ bool isAArch64Auth =
+ ctx.arg.emachine == EM_AARCH64 && type == R_AARCH64_AUTH_ABS64;
- if (sym.isTagged()) {
+ if (sym.isTagged() && !isAArch64Auth) {
----------------
smithp35 wrote:
The TL;DR is that in theory they could be combined. In practice no-one has
tried combining or expressed an interest in combining them. One opinion is that
it could be removed for now, and when someone does try it, they'll need to put
something similar back. Perhaps leave a comment.
>From a user group perspective the PAuthABI and the MemtagABI communities are
>separate. As I understand the PAuthABI is an ABI break for the group using
>Memtag and the group intending to use PAuthABI is targeting hardware that
>doesn't have MTE so can't use the Memtag ABI anyway.
Re-reading the specifications I don't think that there's anything fundamental
at the specification level that would prevent the two being used together. The
PAuthABI adds new relocations, the MemtagABI alters the behaviour of existing
non PAuth ABI relocations. This means that global signed pointers can't be
tagged, but as tagging does not have to be complete, anything that isn't signed
could be tagged.
I expect that the memtag ABI could be extended to cover signed pointers. It
would need to encode the tag offset for relative relocations for
R_AARCH64_AUTH_RELATIVE in a compatible way to the signing schema.
https://github.com/llvm/llvm-project/pull/171180
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
