Add assembler plumbing for sanitize_memtag

[hctim]

Summary

Extends the Asm reader/writer to support reading and writing the
'.memtag' directive (including allowing it on internal global
variables). Also add some extra tooling support, including objdump and
yaml2obj/obj2yaml.

Test that the sanitize_memtag IR attribute produces the expected asm
directive.

Uses the new Aarch64 MemtagABI specification
(https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst)
to identify symbols as tagged in object files. This is done using a
R_AARCH64_NONE relocation that identifies each tagged symbol, and these
relocations are tagged in a special SHT_AARCH64_MEMTAG_GLOBALS_STATIC
section. This signals to the linker that the global variable should be
tagged.

[MaskRay]

This needs a discussion on https://github.com/ARM-software/abi-aa/ . There are not many STO_ bits and I am not sure the usage is worth reserving one bit for it.

[fmayer]

llvm/lib/MC/MCSymbolELF.cpp

39

_Shift for consistency?

204

Consider turning this into explicit branches, which I think is easier to understand. Up to you though.

uint32_t NewFlags;
if (Tagged)
   NewFlags = getFlags() | (1x << ELF_IsMemoryTagged);
else
   NewFlags = getFlags() & ~(1x << ELF_IsMemoryTagged);

[hctim]

In D128958#3624192, @MaskRay wrote:

This needs a discussion on https://github.com/ARM-software/abi-aa/ . There are not many STO_ bits and I am not sure the usage is worth reserving one bit for it.

Reworked: no longer uses st_other bits to signal to the linker to do work - instead, it uses a new android-specific section type filled with R_AARCH64_NONE relocations.

llvm/lib/MC/MCSymbolELF.cpp

204

sure, done, but slightly differently.

[hctim]

Update.

[MaskRay]

llvm/include/llvm/MC/MCDirectives.h

49

So that next time a value is added, no need to touch the MCSA_Tagged line.

llvm/include/llvm/MC/MCELFObjectWriter.h

143

Use imperative sentences. (Omitting s is much more common)

llvm/lib/MC/ELFObjectWriter.cpp

1100

The chunk of code doesn't belong here. See finalizeCGProfile

llvm/lib/MC/MCParser/AsmParser.cpp

5605

The name .tagged is general. Worth using a name more specific to memtag.

llvm/lib/MC/MCSymbolELF.cpp

201

you may omit 0x

207

you may omit 0x

llvm/lib/Target/AArch64/MCTargetDesc/AArch64ELFObjectWriter.cpp

37

459

Omit the variable. Just return

llvm/test/CodeGen/AArch64/global-tagging.ll

3 ↗

(On Diff #442644)

llvm-mc tests belong to test/MC/AArch64

4 ↗

(On Diff #442644)

llvm-readelf -r is better when the number of relocations is to be checked.

6 ↗

(On Diff #442644)

Check D107949 how I add yaml2obj/obj2yaml/llvm-readobj/llvm-objdump. You can use that as the first patch, and llvm-mc support as the second.

12 ↗

(On Diff #442644)

It usually reads better if for a particular check prefix, the content is aligned.

[hctim]

Update with Ray's comments.

llvm/lib/MC/ELFObjectWriter.cpp

1100

I've moved it into a member function, but unlike finalizeCGProfile, we're not writing out a section here, we're only adding a set of relocations (and a special section to hold them). Our section has no bytes, just a set of relocations that reference it.

I don't see any other reasonable places to add this "add some relocations" pass (apart from in the ELFWriter c'tor).

llvm/test/CodeGen/AArch64/global-tagging.ll

6 ↗

(On Diff #442644)

yaml2obj/obj2yaml/llvm-readelf/llvm-objdump here aren't actually being updated (I've removed an ELF note reservation from previous patchsets), they're just being used to check that the .memtag directive forces a relocation. I don't think testing each tool is necessary.

[eugenis]

llvm/include/llvm/MC/MCAsmInfo.h

777

getMemtagAttr ?

llvm/include/llvm/MC/MCSymbolELF.h

47

Why are these names so random?

getMemTag()
setMemTag()

or something similar with "is"

[hctim]

llvm/include/llvm/MC/MCSymbolELF.h

47

done, modelled after setVisibility / getVisibility above

[hctim]

Unify the naming, based on 'Memtag'.

[MaskRay]

The implementation looks good to me. I assume that you have authority to define a value in SHT_ANDROID_*.

My only concern is whether regular AArch64 may need something similar in the future, then whether the section name .memtag.globals and the directive name .memtag may cause a recognition conflict.
Technically the assembler may decode the environment from the target triple (aarch64-linux-android31) and do different things on Android and on non-Android, but I personally favor different section names/directives
which can help Android migrate to the standard.

@Wilco1 @peter.smith

llvm/test/MC/AArch64/global-tagging.ll

7

> => -o

12

Instead of interleaving YAML/RELOCS/ASM checks, I think it seems more readable to group YAML/RELOCS/ASM separately.

[enh]

In D128958#3648965, @MaskRay wrote:

The implementation looks good to me. I assume that you have authority to define a value in SHT_ANDROID_*.

i own Android's elf.h and dynamic linker [citations needed: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/elf.h and https://cs.android.com/android/platform/superproject/+/master:bionic/OWNERS], and this lgtm :-)

My only concern is whether regular AArch64 may need something similar in the future, then whether the section name .memtag.globals and the directive name .memtag may cause a recognition conflict.
Technically the assembler may decode the environment from the target triple (aarch64-linux-android31) and do different things on Android and on non-Android, but I personally favor different section names/directives
which can help Android migrate to the standard.

@Wilco1 @peter.smith

yeah, ideally we'll be able to get everyone in sync in the end, even if we have to ship first (like with the compressed relocations stuff).

[peter.smith]

Purely on the ABI front, I've got some questions and suggestions.

As a general open question, what are your ABI plans? Is it to create an Android specific ABI for .memtag, which presumably will need to be maintained for some period of time? I assume that if there is an alternative Linux ABI defined, presumably in the AArch64 ABI https://github.com/ARM-software/abi-aa then you'll consider adopting that?

As an aside the ABI is open for contributions https://github.com/ARM-software/abi-aa/blob/main/CONTRIBUTING.md if there is an effort to get a memtag ABI defined (not aware of one internally) we'd like to work with everyone to write something up. The PAuthABI (https://discourse.llvm.org/t/llvm-pointer-authentication-sync-ups/62661/5) is an example of that. We have an ELF extension https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst that has some additional relocations and dynamic relocations reserved.

For Arm/AArch64 specific sections, although I can't find it written down as "reserved" we try and follow a naming convention for Arm/AArch64 specific sections such as .ARM.attributes . My expectation is that anything that we define that is SHT_PROGBITS that is specific to Arm/AArch64 will have a .ARM. or .AArch64. prefix. If your section name is specific to Android, but could be supported on other architectures at some future point, could you use something like .Android.memtag?

For the .memtag directive there could be a parameter, potentially optional that changed its behaviour. For example .memtag huge, android .memtag huge, arm. It wouldn't be the end of the world if there had to be a second directive with a different name, although that would be potentially confusing. There doesn't seem to be a naming convention for directives in GNU assembler like there would be section names.

[hctim]

In D128958#3650985, @peter.smith wrote:

Purely on the ABI front, I've got some questions and suggestions.

As a general open question, what are your ABI plans? Is it to create an Android specific ABI for .memtag, which presumably will need to be maintained for some period of time? I assume that if there is an alternative Linux ABI defined, presumably in the AArch64 ABI https://github.com/ARM-software/abi-aa then you'll consider adopting that?

I think the AArch64 ABI is a reasonable place for this - however my main concern is that I have zero experience with non-Android loaders, and no experience with other linkers outside of lld. As such, it's hard to estimate the "unknown unknowns" of those areas.

There is also a separate piece that is part of this work that belongs in the linker. In summary, it's a special section with a series of ULEB-encoded pairs of {offset, size} descriptors (one for each global variable that wants to be tagged).

I'll draft up an MTE AArch64 ABI extension over there, but will probably need some hand holding :).

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations? I would hope that we can avoid a RELR-style launch where Android supports some scheme for a few generations, then the generic ABI variant comes about, and then Android has to support both (and app developers have to use the old one for backwards compatibility, but that's not always obvious).

As an aside the ABI is open for contributions https://github.com/ARM-software/abi-aa/blob/main/CONTRIBUTING.md if there is an effort to get a memtag ABI defined (not aware of one internally) we'd like to work with everyone to write something up. The PAuthABI (https://discourse.llvm.org/t/llvm-pointer-authentication-sync-ups/62661/5) is an example of that. We have an ELF extension https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst that has some additional relocations and dynamic relocations reserved.

Fortunately, the current design fits without having to create new relocations (we did have a previous RFC that required new relocations for optimisation, but that's not our focus right now). We do re-use existing relocation types in a new novel way (like the R_NONE in a special section in this patch, or applications of memory tags in R_RELATIVE and other dynamic relocations).

For Arm/AArch64 specific sections, although I can't find it written down as "reserved" we try and follow a naming convention for Arm/AArch64 specific sections such as .ARM.attributes . My expectation is that anything that we define that is SHT_PROGBITS that is specific to Arm/AArch64 will have a .ARM. or .AArch64. prefix. If your section name is specific to Android, but could be supported on other architectures at some future point, could you use something like .Android.memtag?

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations?

For the .memtag directive there could be a parameter, potentially optional that changed its behaviour. For example .memtag huge, android .memtag huge, arm. It wouldn't be the end of the world if there had to be a second directive with a different name, although that would be potentially confusing. There doesn't seem to be a naming convention for directives in GNU assembler like there would be section names.

Isn't the compile target enough for this? For example, we might also want to (on some Android NDK version gate) do something different, which would be implied by the ## part of the aarch64-linux-android## target. I also believe that the name here is generic enough to be used by other architectures (x86, etc.) in future.

[peter.smith]

In D128958#3653055, @hctim wrote:

In D128958#3650985, @peter.smith wrote:

Purely on the ABI front, I've got some questions and suggestions.

As a general open question, what are your ABI plans? Is it to create an Android specific ABI for .memtag, which presumably will need to be maintained for some period of time? I assume that if there is an alternative Linux ABI defined, presumably in the AArch64 ABI https://github.com/ARM-software/abi-aa then you'll consider adopting that?

I think the AArch64 ABI is a reasonable place for this - however my main concern is that I have zero experience with non-Android loaders, and no experience with other linkers outside of lld. As such, it's hard to estimate the "unknown unknowns" of those areas.

There is also a separate piece that is part of this work that belongs in the linker. In summary, it's a special section with a series of ULEB-encoded pairs of {offset, size} descriptors (one for each global variable that wants to be tagged).

I'll draft up an MTE AArch64 ABI extension over there, but will probably need some hand holding :).

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations? I would hope that we can avoid a RELR-style launch where Android supports some scheme for a few generations, then the generic ABI variant comes about, and then Android has to support both (and app developers have to use the old one for backwards compatibility, but that's not always obvious).

Thank you. The best place to start would be to raise a github issue https://github.com/ARM-software/abi-aa/issues to cover the overall addition. If you can put a summary (or link to a description elsewhere) of what all the parts to the extension are in the issue then we can advise on the best way forward.

We do have people from our GNU team that have some experience of glibc and GNU ld so hopefully we can find anything that wouldn't be implementable in these areas.

As an aside the ABI is open for contributions https://github.com/ARM-software/abi-aa/blob/main/CONTRIBUTING.md if there is an effort to get a memtag ABI defined (not aware of one internally) we'd like to work with everyone to write something up. The PAuthABI (https://discourse.llvm.org/t/llvm-pointer-authentication-sync-ups/62661/5) is an example of that. We have an ELF extension https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst that has some additional relocations and dynamic relocations reserved.

Fortunately, the current design fits without having to create new relocations (we did have a previous RFC that required new relocations for optimisation, but that's not our focus right now). We do re-use existing relocation types in a new novel way (like the R_NONE in a special section in this patch, or applications of memory tags in R_RELATIVE and other dynamic relocations).

For Arm/AArch64 specific sections, although I can't find it written down as "reserved" we try and follow a naming convention for Arm/AArch64 specific sections such as .ARM.attributes . My expectation is that anything that we define that is SHT_PROGBITS that is specific to Arm/AArch64 will have a .ARM. or .AArch64. prefix. If your section name is specific to Android, but could be supported on other architectures at some future point, could you use something like .Android.memtag?

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations?

If we've got the opportunity to change while the feature is in development then either one is fine. In the ABI we've not yet got any .aarch64. reservations yet. We have .ARM.attributes reserved for BuildAttributes but I'm unsure whether the intent was that .ARM. would be the prefix for AArch64 or the more likely case that .ARM.attributes was chosen as existing tools already recognised that section name from the 32-bit ABI. At the moment the Android reservation is outside of anything Arm would define so you have a guarantee of no name clash if the ABI process falls through for any reason. If we can make the AArch64 ABI work then I hope it would be possible to change it later.

For the .memtag directive there could be a parameter, potentially optional that changed its behaviour. For example .memtag huge, android .memtag huge, arm. It wouldn't be the end of the world if there had to be a second directive with a different name, although that would be potentially confusing. There doesn't seem to be a naming convention for directives in GNU assembler like there would be section names.

Isn't the compile target enough for this? For example, we might also want to (on some Android NDK version gate) do something different, which would be implied by the ## part of the aarch64-linux-android## target. I also believe that the name here is generic enough to be used by other architectures (x86, etc.) in future.

The target is enough, we'd have to be careful in the tests to not abbreviate the triple too much but that is not a major problem.

[enh]

In D128958#3653055, @hctim wrote:

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations? I would hope that we can avoid a RELR-style launch where Android supports some scheme for a few generations, then the generic ABI variant comes about, and then Android has to support both (and app developers have to use the old one for backwards compatibility, but that's not always obvious).

fwiw, i don't think this case is as bad as compressed relocations because there's no NDK MTE ABI anyway, so this would only affect platform code. it would be annoying for SoC vendors/OEMs needing to rebuild prebuilts (and we'd need the backwards compatibility for 3+ years so that new system image + old vendor image still worked), but at least this wouldn't leak to app developers.

that said, it would still be ideal to get to an official ARM ABI before Android U is finalized early next year --- that would make it more likely we can avoid any disruption.

[hctim]

In D128958#3710572, @enh wrote:

In D128958#3653055, @hctim wrote:

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use aarch64 reservations, or Android reservations? I would hope that we can avoid a RELR-style launch where Android supports some scheme for a few generations, then the generic ABI variant comes about, and then Android has to support both (and app developers have to use the old one for backwards compatibility, but that's not always obvious).

fwiw, i don't think this case is as bad as compressed relocations because there's no NDK MTE ABI anyway, so this would only affect platform code. it would be annoying for SoC vendors/OEMs needing to rebuild prebuilts (and we'd need the backwards compatibility for 3+ years so that new system image + old vendor image still worked), but at least this wouldn't leak to app developers.

that said, it would still be ideal to get to an official ARM ABI before Android U is finalized early next year --- that would make it more likely we can avoid any disruption.

I think it could leak to very progressive app developers - globals are tagged on a per-DSO basis and (at least now) dlopen doesn't discriminate between platform DSOs and app DSOs.

We could change that if we didn't want to have ABI problems, but if we ship MTE globals in an apex, we need the backwards compatibility anyway.

In the MemtagABI doc I'm drafting it also has dynamic table entries so that we can move off of the elf note for specifying heap/stack/etc., so that'd need to stick around for a few generations as well.

I think we'll just end up supporting both an old and a new for a few generations anyway.

[hctim]

I've uploaded the first draft of the MemtagABI in https://github.com/ARM-software/abi-aa/pull/166

Please send ABI discussion over there.

For now, I'll change any implementation semantics to reflect that draft ABI and use some identifiers in the OS-experimental ranges to allow this to be upstreamed without dependencies on the ABI approval. We'll consider it an experimental ABI for Android use, but not plan to ship any of it right now.

[peter.smith]

Thanks very much for writing the ABI doc. Will take a look and leave comments on the pull request.

[hctim]

Addressed the outstanding comments. Moved the Android-specific section name to line up with the MemtagABI name (just in the Android-specific space until that ABI is merged - in order to unblock our testing/merging).

[hctim]

@peter.smith, @MaskRay, @eugenis - would you mind taking a final review of this please? ELF types are Android-specific variants of those described in the MemtagABI draft (https://github.com/ARM-software/abi-aa/pull/166), so that we can merge this for Android testing.

[peter.smith]

I can take a look from the perspective of the ABI, not too familiar with the implementation but will try my best. I'm running a bit behind schedule so it may be a few days before I can comment. Very happy if others want to approve, particularly on the implementation.

[peter.smith]

One really small comment, that is only a suggestion. This looks good to me. I've set approved, but please give a bit of time to see if there are any objections.

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

716

For the moment is it worth extending the check to an Android OS, that could be going over the top though.

[hctim]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

716

done, and moved from assert -> error.

[hctim]

Update w/ comments.

[hctim]

Move some existing stack tests to use -fsanitize=memtag-stack now that we have a non-android warning on -fsanitize=memtag-globals (which is implied by -fsantize=memtag, which the tests previously used).

[eugenis]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

715

isTagged() already includes a check for hasSanitizerMetadata()

[hctim]

Remove unnecessary hasSanitizerMetadata()

[hctim]

Use new MemtagABI section types, now that it's merged upstream: https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst

[fmayer]

llvm/lib/MC/ELFObjectWriter.cpp

623

Is the story here that on non-AArch64, this function gets run, but there will be no SymE.isMemtag()?

1335–1342

move this after the assert for Sym

[hctim]

Move isMemtag below assert(Sym)

[fmayer]

llvm/lib/MC/ELFObjectWriter.cpp

623

optional: the assert message does not really convey that. Maybe something like "Unexpectedly found tagged global"

[hctim]

Update comment for .memtag globals when generating object files on non-MTE-globals supported architectures, and move said comment from an assert to a fatal error.

llvm/lib/MC/ELFObjectWriter.cpp

623

Correct, and getMemtagRelocsSection() returns nullptr on every arch except aarch64.

clang/test/Driver/memtag-stack.c

-// RUN: %clang     -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-SAFETY
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
-// RUN: %clang -O2 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
-// RUN: %clang -O3 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang     -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-SAFETY
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O2 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
+// RUN: %clang -O3 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print=1 %s -S -o - 2>&1 | FileCheck %s --check-prefix=CHECK-SAFETY
 
 // REQUIRES: aarch64-registered-target
 
 int z;
 __attribute__((noinline)) void use(int *p) { *p = z; }
 int foo() {
   int x;
   use(&x);
   return x;
 }
 
 // CHECK-NO-SAFETY-NOT: allocas uses
 
 // CHECK-SAFETY-LABEL: @foo
 // CHECK-SAFETY-LABEL: allocas uses:
 // CHECK-SAFETY-NEXT: [4]: [0,4)

clang/test/Driver/memtag-stack_lto.c

 // RUN:  -r %t.thinltonewpm1.bc,w, \
 // RUN:  -r %t.thinltonewpm2.bc,use,plx \
 // RUN:  -r %t.thinltonewpm2.bc,z, 2>&1 | FileCheck %s --allow-empty
 
 // Now with MTE.
 // RUN: rm -f %t*
 
 // -O0: both are unsafe.
-// RUN: %clang -O0 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print %s -S -o - 2>&1 | FileCheck %s
+// RUN: %clang -O0 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print %s -S -o - 2>&1 | FileCheck %s
 
 // No LTO: just one is safe.
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -mllvm -stack-safety-print %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefixes=SSI,XUNSAFE,YSAFE
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -mllvm -stack-safety-print %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefixes=SSI,XUNSAFE,YSAFE
 
 // Full LTO: both are safe.
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -c %s -Xclang -opaque-pointers -flto=full -o %t.ltonewpm1.bc
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -c -DBUILD2 %s -Xclang -opaque-pointers -flto=full -o %t.ltonewpm2.bc
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -c %s -Xclang -opaque-pointers -flto=full -o %t.ltonewpm1.bc
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -c -DBUILD2 %s -Xclang -opaque-pointers -flto=full -o %t.ltonewpm2.bc
 // RUN: llvm-lto2 run -lto-opaque-pointers -o %t.ltonewpm %t.ltonewpm1.bc %t.ltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
 // RUN:  -r %t.ltonewpm1.bc,fn,plx \
 // RUN:  -r %t.ltonewpm1.bc,use,lx \
 // RUN:  -r %t.ltonewpm1.bc,use_local,plx \
 // RUN:  -r %t.ltonewpm1.bc,w, \
 // RUN:  -r %t.ltonewpm2.bc,use,plx \
 // RUN:  -r %t.ltonewpm2.bc,z, 2>&1 | FileCheck %s -check-prefixes=SSI,XSAFE,YSAFE
 
 // Thin LTO: both are safe.
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -c %s -Xclang -opaque-pointers -flto=thin -o %t.thinltonewpm1.bc
-// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag -c -DBUILD2 %s -Xclang -opaque-pointers -flto=thin -o %t.thinltonewpm2.bc
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -c %s -Xclang -opaque-pointers -flto=thin -o %t.thinltonewpm1.bc
+// RUN: %clang -O1 -target aarch64-unknown-linux -march=armv8+memtag -fsanitize=memtag-stack -c -DBUILD2 %s -Xclang -opaque-pointers -flto=thin -o %t.thinltonewpm2.bc
 // RUN: llvm-lto2 run -lto-opaque-pointers -o %t.thinltonewpm %t.thinltonewpm1.bc %t.thinltonewpm2.bc -save-temps -stack-safety-print -thinlto-threads 1 -O1 \
 // RUN:  -r %t.thinltonewpm1.bc,fn,plx \
 // RUN:  -r %t.thinltonewpm1.bc,use,lx \
 // RUN:  -r %t.thinltonewpm1.bc,use_local,plx \
 // RUN:  -r %t.thinltonewpm1.bc,w, \
 // RUN:  -r %t.thinltonewpm2.bc,use,plx \
 // RUN:  -r %t.thinltonewpm2.bc,z, 2>&1 | FileCheck %s -check-prefixes=SSI,XSAFE,YSAFE
 

llvm/include/llvm/BinaryFormat/ELF.h

enum : unsigned {
   // Exception Index table
   SHT_ARM_EXIDX = 0x70000001U,
   // BPABI DLL dynamic linking pre-emption map
   SHT_ARM_PREEMPTMAP = 0x70000002U,
   //  Object file compatibility attributes
   SHT_ARM_ATTRIBUTES = 0x70000003U,
   SHT_ARM_DEBUGOVERLAY = 0x70000004U,
   SHT_ARM_OVERLAYSECTION = 0x70000005U,
+  // Special aarch64-specific sections for MTE support, as described in:
+  // https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst#7section-types
+  SHT_AARCH64_MEMTAG_GLOBALS_STATIC = 0x70000007U,
+  SHT_AARCH64_MEMTAG_GLOBALS_DYNAMIC = 0x70000008U,
   SHT_HEX_ORDERED = 0x70000000,   // Link editor is to sort the entries in
                                   // this section based on their sizes
   SHT_X86_64_UNWIND = 0x70000001, // Unwind information
 
   SHT_MIPS_REGINFO = 0x70000006,  // Register usage information
   SHT_MIPS_OPTIONS = 0x7000000d,  // General options
   SHT_MIPS_DWARF = 0x7000001e,    // DWARF debugging section.
   SHT_MIPS_ABIFLAGS = 0x7000002a, // ABI information.

llvm/include/llvm/MC/MCAsmInfo.h

protected:
   /// This attribute, if not MCSA_Invalid, is used to declare an undefined
   /// symbol as having hidden visibility. Defaults to MCSA_Hidden.
   MCSymbolAttr HiddenDeclarationVisibilityAttr = MCSA_Hidden;
 
   /// This attribute, if not MCSA_Invalid, is used to declare a symbol as having
   /// protected visibility.  Defaults to MCSA_Protected
   MCSymbolAttr ProtectedVisibilityAttr = MCSA_Protected;
 
+  MCSymbolAttr MemtagAttr = MCSA_Memtag;
+
   //===--- Dwarf Emission Directives -----------------------------------===//
 
   /// True if target supports emission of debugging information.  Defaults to
   /// false.
   bool SupportsDebugInformation = false;
 
   /// Exception handling format for the target.  Defaults to None.
   ExceptionHandling ExceptionsType = ExceptionHandling::None;
public:
   MCSymbolAttr getHiddenDeclarationVisibilityAttr() const {
     return HiddenDeclarationVisibilityAttr;
   }
 
   MCSymbolAttr getProtectedVisibilityAttr() const {
     return ProtectedVisibilityAttr;
   }
 
+  MCSymbolAttr getMemtagAttr() const { return MemtagAttr; }
+
   bool doesSupportDebugInformation() const { return SupportsDebugInformation; }
 
   ExceptionHandling getExceptionHandlingType() const { return ExceptionsType; }
   WinEH::EncodingType getWinEHEncodingType() const { return WinEHEncodingType; }
 
   void setExceptionsType(ExceptionHandling EH) {
     ExceptionsType = EH;
   }

llvm/include/llvm/MC/MCDirectives.h

enum MCSymbolAttr {
   MCSA_SymbolResolver,          ///< .symbol_resolver (MachO)
   MCSA_AltEntry,                ///< .alt_entry (MachO)
   MCSA_PrivateExtern,           ///< .private_extern (MachO)
   MCSA_Protected,               ///< .protected (ELF)
   MCSA_Reference,               ///< .reference (MachO)
   MCSA_Weak,                    ///< .weak
   MCSA_WeakDefinition,          ///< .weak_definition (MachO)
   MCSA_WeakReference,           ///< .weak_reference (MachO)
-  MCSA_WeakDefAutoPrivate       ///< .weak_def_can_be_hidden (MachO)
+  MCSA_WeakDefAutoPrivate,      ///< .weak_def_can_be_hidden (MachO)
+  MCSA_Memtag,                  ///< .memtag (ELF)
 };
 
 enum MCAssemblerFlag {
   MCAF_SyntaxUnified,         ///< .syntax (ARM/ELF)
   MCAF_SubsectionsViaSymbols, ///< .subsections_via_symbols (MachO)
   MCAF_Code16,                ///< .code16 (X86) / .code 16 (ARM)
   MCAF_Code32,                ///< .code32 (X86) / .code 32 (ARM)
   MCAF_Code64                 ///< .code64 (X86)

llvm/include/llvm/MC/MCELFObjectWriter.h

#define R_SSYM_MASK 0x00ffffff
   static unsigned setRTypes(unsigned Value1, unsigned Value2, unsigned Value3) {
     return ((Value1 & 0xff) << R_TYPE_SHIFT) |
            ((Value2 & 0xff) << R_TYPE2_SHIFT) |
            ((Value3 & 0xff) << R_TYPE3_SHIFT);
   }
   unsigned setRSsym(unsigned Value, unsigned Type) const {
     return (Type & R_SSYM_MASK) | ((Value & 0xff) << R_SSYM_SHIFT);
   }
+
+  // On AArch64, return a new section to be added to the ELF object that
+  // contains relocations used to describe every symbol that should have memory
+  // tags applied. Returns nullptr if no such section is necessary (i.e. there's
+  // no tagged globals).
+  virtual MCSectionELF *getMemtagRelocsSection(MCContext &Ctx) const {
+    return nullptr;
+  }
 };
 
 /// Construct a new ELF writer instance.
 ///
 /// \param MOTW - The target specific ELF writer subclass.
 /// \param OS - The stream to write to.
 /// \returns The constructed object writer.
 std::unique_ptr<MCObjectWriter>

llvm/include/llvm/MC/MCSymbolELF.h

public:
   bool isBindingSet() const;
 
   void setIsWeakrefUsedInReloc() const;
   bool isWeakrefUsedInReloc() const;
 
   void setIsSignature() const;
   bool isSignature() const;
 
+  void setMemtag(bool Tagged);
+  bool isMemtag() const;
+
   static bool classof(const MCSymbol *S) { return S->isELF(); }
 
 private:
   void setIsBindingSet() const;
 };
 }
 
 #endif

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

void AsmPrinter::emitGlobalVariable(const GlobalVariable *GV) {
   MCSymbol *GVSym = getSymbol(GV);
   MCSymbol *EmittedSym = GVSym;
 
   // getOrCreateEmuTLSControlSym only creates the symbol with name and default
   // attributes.
   // GV's or GVSym's attributes will be used for the EmittedSym.
   emitVisibility(EmittedSym, GV->getVisibility(), !GV->isDeclaration());
 
+  if (GV->isTagged()) {
+    Triple T = TM.getTargetTriple();
+
+    if (T.getArch() != Triple::aarch64 || !T.isAndroid())
+      OutContext.reportError(SMLoc(),
+                             "Tagged symbols (-fsanitize=memtag-globals) are "
+                             "only supported on aarch64 + Android.");
+    OutStreamer->emitSymbolAttribute(EmittedSym, MAI->getMemtagAttr());
+  }
+
   if (!GV->hasInitializer())   // External globals require no extra code.
     return;
 
   GVSym->redefineIfPossible();
   if (GVSym->isDefined() || GVSym->isVariable())
     OutContext.reportError(SMLoc(), "symbol '" + Twine(GVSym->getName()) +
                                         "' is already defined");
 

llvm/lib/MC/ELFObjectWriter.cpp

void computeSymbolTable(MCAssembler &Asm, const MCAsmLayout &Layout,
                           const RevGroupMapTy &RevGroupMap,
                           SectionOffsetsTy &SectionOffsets);
 
   void writeAddrsigSection();
 
   MCSectionELF *createRelocationSection(MCContext &Ctx,
                                         const MCSectionELF &Sec);
 
+  void createMemtagRelocs(MCAssembler &Asm);
+
   void writeSectionHeader(const MCAsmLayout &Layout,
                           const SectionIndexMapTy &SectionIndexMap,
                           const SectionOffsetsTy &SectionOffsets);
 
   void writeSectionData(const MCAssembler &Asm, MCSection &Sec,
                         const MCAsmLayout &Layout);
 
   void WriteSecHdrEntry(uint32_t Name, uint32_t Type, uint64_t Flags,
if (Symbol.isTemporary())
     return false;
 
   if (Symbol.getType() == ELF::STT_SECTION)
     return false;
 
   return true;
 }
 
+void ELFWriter::createMemtagRelocs(MCAssembler &Asm) {
+  MCSectionELF *MemtagRelocs = nullptr;
+  for (const MCSymbol &Sym : Asm.symbols()) {
+    const auto &SymE = cast<MCSymbolELF>(Sym);
+    if (!SymE.isMemtag())
+      continue;
+    if (MemtagRelocs == nullptr) {
+      MemtagRelocs = OWriter.TargetObjectWriter->getMemtagRelocsSection(Asm.getContext());
+      if (MemtagRelocs == nullptr)
+        report_fatal_error("Tagged globals are not available on this architecture.");
+      Asm.registerSection(*MemtagRelocs);
+    }
+    ELFRelocationEntry Rec(0, &SymE, ELF::R_AARCH64_NONE, 0, nullptr, 0);
+    OWriter.Relocations[MemtagRelocs].push_back(Rec);
+  }
+}
+
 void ELFWriter::computeSymbolTable(
     MCAssembler &Asm, const MCAsmLayout &Layout,
     const SectionIndexMapTy &SectionIndexMap, const RevGroupMapTy &RevGroupMap,
     SectionOffsetsTy &SectionOffsets) {
   MCContext &Ctx = Asm.getContext();
   SymbolTableWriter Writer(*this, is64Bit());
 
   // Symbol table

 uint64_t ELFWriter::writeObject(MCAssembler &Asm, const MCAsmLayout &Layout) {
   uint64_t StartOffset = W.OS.tell();
 
   MCContext &Ctx = Asm.getContext();
   MCSectionELF *StrtabSection =
       Ctx.getELFSection(".strtab", ELF::SHT_STRTAB, 0);
   StringTableIndex = addToSectionTable(StrtabSection);
 
+  createMemtagRelocs(Asm);
+
   RevGroupMapTy RevGroupMap;
   SectionIndexMapTy SectionIndexMap;
 
   std::map<const MCSymbol *, std::vector<const MCSectionELF *>> GroupMembers;
 
   // Write out the ELF header ...
   writeHeader(Asm);
 
   // ... then the sections ...
   SectionOffsetsTy SectionOffsets;
   std::vector<MCSectionELF *> Groups;
   std::vector<MCSectionELF *> Relocations;
   for (MCSection &Sec : Asm) {
     MCSectionELF &Section = static_cast<MCSectionELF &>(Sec);
     if (Mode == NonDwoOnly && isDwoSection(Section))
       continue;
     if (Mode == DwoOnly && !isDwoSection(Section))
bool ELFObjectWriter::shouldRelocateWithSymbol(const MCAssembler &Asm,
   case MCSymbolRefExpr::VK_GOTPCREL:
   case MCSymbolRefExpr::VK_GOTPCREL_NORELAX:
   case MCSymbolRefExpr::VK_PPC_GOT_LO:
   case MCSymbolRefExpr::VK_PPC_GOT_HI:
   case MCSymbolRefExpr::VK_PPC_GOT_HA:
     return true;
   }
 
   // An undefined symbol is not in any section, so the relocation has to point
   // to the symbol itself.
   assert(Sym && "Expected a symbol");
   if (Sym->isUndefined())
     return true;
 
+  // For memory-tagged symbols, ensure that the relocation uses the symbol. For
+  // tagged symbols, we emit an empty relocation (R_AARCH64_NONE) in a special
+  // section (SHT_AARCH64_MEMTAG_GLOBALS_STATIC) to indicate to the linker that
+  // this global needs to be tagged. In addition, the linker needs to know
+  // whether to emit a special addend when relocating `end` symbols, and this
+  // can only be determined by the attributes of the symbol itself.
+  if (Sym->isMemtag())
+    return true;
+
   unsigned Binding = Sym->getBinding();
   switch(Binding) {
   default:
     llvm_unreachable("Invalid Binding");
   case ELF::STB_LOCAL:
     break;
   case ELF::STB_WEAK:
     // If the symbol is weak, it might be overridden by a symbol in another

llvm/lib/MC/MCAsmStreamer.cpp

break;
       // .weak_reference
   case MCSA_WeakReference:  OS << MAI->getWeakRefDirective(); break;
   case MCSA_WeakDefAutoPrivate: OS << "\t.weak_def_can_be_hidden\t"; break;
   case MCSA_Cold:
     // Assemblers currently do not support a .cold directive.
   case MCSA_Exported:
     // Non-AIX assemblers currently do not support exported visibility.
     return false;
+  case MCSA_Memtag:
+    OS << "\t.memtag\t";
+    break;
   }
 
   Symbol->print(OS, MAI);
   EmitEOL();
 
   return true;
 }
 

llvm/lib/MC/MCELFStreamer.cpp

bool MCELFStreamer::emitSymbolAttribute(MCSymbol *S, MCSymbolAttr Attribute) {
   case MCSA_ELF_TypeNoType:
     Symbol->setType(CombineSymbolTypes(Symbol->getType(), ELF::STT_NOTYPE));
     break;
 
   case MCSA_Protected:
     Symbol->setVisibility(ELF::STV_PROTECTED);
     break;
 
+  case MCSA_Memtag:
+    Symbol->setMemtag(true);
+    break;
+
   case MCSA_Hidden:
     Symbol->setVisibility(ELF::STV_HIDDEN);
     break;
 
   case MCSA_Internal:
     Symbol->setVisibility(ELF::STV_INTERNAL);
     break;
 

llvm/lib/MC/MCMachOStreamer.cpp

bool MCMachOStreamer::emitSymbolAttribute(MCSymbol *Sym,
   case MCSA_Hidden:
   case MCSA_IndirectSymbol:
   case MCSA_Internal:
   case MCSA_Protected:
   case MCSA_Weak:
   case MCSA_Local:
   case MCSA_LGlobal:
   case MCSA_Exported:
+  case MCSA_Memtag:
     return false;
 
   case MCSA_Global:
     Symbol->setExternal(true);
     // This effectively clears the undefined lazy bit, in Darwin 'as', although
     // it isn't very consistent because it implements this as part of symbol
     // lookup.
     //

llvm/lib/MC/MCParser/AsmParser.cpp

enum DirectiveKind {
     DK_WARNING,
     DK_PRINT,
     DK_ADDRSIG,
     DK_ADDRSIG_SYM,
     DK_PSEUDO_PROBE,
     DK_LTO_DISCARD,
     DK_LTO_SET_CONDITIONAL,
     DK_CFI_MTE_TAGGED_FRAME,
+    DK_MEMTAG,
     DK_END
   };
 
   /// Maps directive name --> DirectiveKind enum, for
   /// directives parsed by this class.
   StringMap<DirectiveKind> DirectiveKindMap;
 
   // Codeview def_range type parsing.
if (IDVal.startswith(".") && IDVal != ".") {
     case DK_ADDRSIG:
       return parseDirectiveAddrsig();
     case DK_ADDRSIG_SYM:
       return parseDirectiveAddrsigSym();
     case DK_PSEUDO_PROBE:
       return parseDirectivePseudoProbe();
     case DK_LTO_DISCARD:
       return parseDirectiveLTODiscard();
+    case DK_MEMTAG:
+      return parseDirectiveSymbolAttribute(MCSA_Memtag);
     }
 
     return Error(IDLoc, "unknown directive");
   }
 
   // __asm _emit or __asm __emit
   if (ParsingMSInlineAsm && (IDVal == "_emit" || IDVal == "__emit" ||
                              IDVal == "_EMIT" || IDVal == "__EMIT"))
auto parseOp = [&]() -> bool {
     if (parseIdentifier(Name))
       return Error(Loc, "expected identifier");
 
     if (discardLTOSymbol(Name))
       return false;
 
     MCSymbol *Sym = getContext().getOrCreateSymbol(Name);
 
-    // Assembler local symbols don't make any sense here. Complain loudly.
-    if (Sym->isTemporary())
+    // Assembler local symbols don't make any sense here, except for directives
+    // that the symbol should be tagged.
+    if (Sym->isTemporary() && Attr != MCSA_Memtag)
       return Error(Loc, "non-local symbol required");
 
     if (!getStreamer().emitSymbolAttribute(Sym, Attr))
       return Error(Loc, "unable to emit symbol attribute");
     return false;
   };
 
   return parseMany(parseOp);
void AsmParser::initializeDirectiveKindMap() {
   DirectiveKindMap[".ds.w"] = DK_DS_W;
   DirectiveKindMap[".ds.x"] = DK_DS_X;
   DirectiveKindMap[".print"] = DK_PRINT;
   DirectiveKindMap[".addrsig"] = DK_ADDRSIG;
   DirectiveKindMap[".addrsig_sym"] = DK_ADDRSIG_SYM;
   DirectiveKindMap[".pseudoprobe"] = DK_PSEUDO_PROBE;
   DirectiveKindMap[".lto_discard"] = DK_LTO_DISCARD;
   DirectiveKindMap[".lto_set_conditional"] = DK_LTO_SET_CONDITIONAL;
+  DirectiveKindMap[".memtag"] = DK_MEMTAG;
 }
 
 MCAsmMacro *AsmParser::parseMacroLikeBody(SMLoc DirectiveLoc) {
   AsmToken EndToken, StartToken = getTok();
 
   unsigned NestLevel = 0;
   while (true) {
     // Check whether we have reached the end of the file.

llvm/lib/MC/MCSymbolELF.cpp

enum {
 
   // One bit.
   ELF_IsSignature_Shift = 10,
 
   // One bit.
   ELF_WeakrefUsedInReloc_Shift = 11,
 
   // One bit.
-  ELF_BindingSet_Shift = 12
+  ELF_BindingSet_Shift = 12,
+
+  // One bit.
+  ELF_IsMemoryTagged_Shift = 13,
 };
 }
 
 void MCSymbolELF::setBinding(unsigned Binding) const {
   setIsBindingSet();
   unsigned Val;
   switch (Binding) {
   default:

 void MCSymbolELF::setIsBindingSet() const {
   uint32_t OtherFlags = getFlags() & ~(0x1 << ELF_BindingSet_Shift);
   setFlags(OtherFlags | (1 << ELF_BindingSet_Shift));
 }
 
 bool MCSymbolELF::isBindingSet() const {
   return getFlags() & (0x1 << ELF_BindingSet_Shift);
 }
+
+bool MCSymbolELF::isMemtag() const {
+  return getFlags() & (0x1 << ELF_IsMemoryTagged_Shift);
+}
+
+void MCSymbolELF::setMemtag(bool Tagged) {
+  uint32_t OtherFlags = getFlags() & ~(1 << ELF_IsMemoryTagged_Shift);
+  if (Tagged)
+    setFlags(OtherFlags | (1 << ELF_IsMemoryTagged_Shift));
+  else
+    setFlags(OtherFlags);
+}
 }

llvm/lib/Target/AArch64/MCTargetDesc/AArch64ELFObjectWriter.cpp

 namespace {
 
 class AArch64ELFObjectWriter : public MCELFObjectTargetWriter {
 public:
   AArch64ELFObjectWriter(uint8_t OSABI, bool IsILP32);
 
   ~AArch64ELFObjectWriter() override = default;
 
+  MCSectionELF *getMemtagRelocsSection(MCContext &Ctx) const override;
+
 protected:
   unsigned getRelocType(MCContext &Ctx, const MCValue &Target,
                         const MCFixup &Fixup, bool IsPCRel) const override;
   bool IsILP32;
 };
 
 } // end anonymous namespace
 
default:
       Ctx.reportError(Fixup.getLoc(), "Unknown ELF relocation type");
       return ELF::R_AARCH64_NONE;
     }
   }
 
   llvm_unreachable("Unimplemented fixup -> relocation");
 }
 
+MCSectionELF *
+AArch64ELFObjectWriter::getMemtagRelocsSection(MCContext &Ctx) const {
+  return Ctx.getELFSection(".memtag.globals.static",
+                           ELF::SHT_AARCH64_MEMTAG_GLOBALS_STATIC, 0);
+}
+
 std::unique_ptr<MCObjectTargetWriter>
 llvm::createAArch64ELFObjectWriter(uint8_t OSABI, bool IsILP32) {
   return std::make_unique<AArch64ELFObjectWriter>(OSABI, IsILP32);
 }

llvm/test/MC/AArch64/global-tagging.ll

+;; Tagged symbols are only available on aarch64-linux-android.
+; RUN: not llc %s -mtriple=aarch64-linux-unknown
+; RUN: not llc %s -mtriple=x86_64-linux-unknown
+
+; RUN: llc %s -mtriple=aarch64-linux-android31 -o %t.S
+; RUN: FileCheck %s --input-file=%t.S --check-prefix=CHECK-ASM
+; RUN: llvm-mc -filetype=obj %t.S -triple=aarch64-linux-android31 -o %t.o
+; RUN: llvm-readelf -r %t.o | FileCheck %s --check-prefix=CHECK-RELOCS
+
+; RUN: obj2yaml %t.o -o %t.yaml
+; RUN: FileCheck %s --input-file=%t.yaml --check-prefix=CHECK-YAML
+; RUN: yaml2obj %t.yaml -o %t.o
+; RUN: llvm-readelf -r %t.o | FileCheck %s --check-prefix=CHECK-RELOCS
+
+; CHECK-RELOCS:     Relocation section '.rela.memtag.globals.static' {{.*}} contains 4 entries
+; CHECK-RELOCS:     R_AARCH64_NONE {{.*}} internal_four
+; CHECK-RELOCS:     R_AARCH64_NONE {{.*}} four
+; CHECK-RELOCS:     R_AARCH64_NONE {{.*}} sixteen
+; CHECK-RELOCS:     R_AARCH64_NONE {{.*}} huge
+; CHECK-RELOCS-NOT: specialcaselisted
+
+; CHECK-YAML:      Sections:
+; CHECK-YAML:      - Name: .rela.memtag.globals.static
+; CHECK-YAML-NOT:  - Name:
+; CHECK-YAML:      Relocations:
+; CHECK-YAML-NEXT: - Symbol: internal_four
+; CHECK-YAML-NEXT: Type: R_AARCH64_NONE
+; CHECK-YAML-NEXT: - Symbol: four
+; CHECK-YAML-NEXT: Type: R_AARCH64_NONE
+; CHECK-YAML-NEXT: - Symbol: sixteen
+; CHECK-YAML-NEXT: Type: R_AARCH64_NONE
+; CHECK-YAML-NEXT: - Symbol: huge
+; CHECK-YAML-NEXT: Type: R_AARCH64_NONE
+; CHECK-YAML-NEXT: -
+
+; CHECK-ASM: .memtag internal_four
+; CHECK-ASM: .memtag four
+; CHECK-ASM: .memtag sixteen
+; CHECK-ASM: .memtag huge
+; CHECK-ASM-NOT: .memtag specialcaselisted
+
+@internal_four = internal global i32 1, sanitize_memtag
+@four = global i32 1, sanitize_memtag
+@sixteen = global [16 x i8] zeroinitializer, sanitize_memtag
+@huge = global [16777232 x i8] zeroinitializer, sanitize_memtag
+@specialcaselisted = global i16 2