[lldb] Remove non-address bits from read/write addresses in lldb

[DavidSpickett]

Summary

Non-address bits are not part of the virtual address in a pointer.
So they must be removed before passing to interfaces like ptrace.

Some of them we get way with not removing, like AArch64's top byte.
However this is only because of a hardware feature that ignores them.

This change updates all the Process/Target Read/Write memory methods
to remove non-address bits before using addresses.

Doing it in this way keeps lldb-server simple and also fixes the
memory caching when differently tagged pointers for the same location
are read.

Removing the bits is done at the ReadMemory level not DoReadMemory
because particualrly for process, many subclasses override DoReadMemory.

Tests have been added for read/write at the command and API level,
for process and target. This includes variants like
Read<sometype>FromMemory. Commands are tested to make sure we remove
at the command and API level.

"memory find" is not included because:

• There is no API for it.
• It already has its own address handling tests.

Software breakpoints do use these methods but they are not tested
here because there are bigger issues to fix with those. This will
happen in another change.

[DavidSpickett]

Without this change any memory read/write of a pointer with a signature would fail. I found it trying to extend memory find and using a pointer with both a signature and a memory tag.

There's a couple of things I could do but not sure if worth it right now given that AArch64 Linux is the only user of non-address bits aside from Mac OS (which has debugserver so that may already be doing this). Those are:

• Sink the application of top byte ignore into NativeRegisterContextLinux_AArch64
• Raise the whole masking process up to NativeProcessProtocol

The latter would implement this logic for every NativeProcess at once but has the issues that:

• most won't have a named register like linux has, so we end up adding an OS specific branch anyway
• Many more functions at NativeProcessProtocol level take an address. The current way lets us fix the few ptrace calls all those member functions actually end up using.

Or in other words: this is a bit hacky but perhaps it should stay that way until it's more widely needed.

I also thought about fixing this from the lldb end but it seems logical to make the server act correctly even without having lldb clean the addresses up front. (though in a some cases, like memory tags, it will do but for its own reasons)

[DavidSpickett]

Also if anyone does know how or if debugserver handles this situation, that would be good to know.

[labath]

I haven't been following the pointer authentication work very much, but I am somewhat surprised that this part is done in lldb-server. I would have expected that lldb would strip these tags before the address makes it's way over here (I'm pretty sure it needs to do that for other uses anyway). Why is that not happening?

[DavidSpickett]

I would have expected that lldb would strip these tags before the address makes it's way over here (I'm pretty sure it needs to do that for other uses anyway). Why is that not happening?

So far we remove non-address bits for commands that need to diff pointers, memory read the obvious example. So memory write currently does not. memory region does but we don't send the address to lldb-server in that case, so it's not quite the same situation.

I'm not wedded to doing it in lldb-server, but it does have the advantage of being at a low level to catch all the possible accesses. At the expense of more complication server side. But you're right that in a lot of cases we'd need to do it in lldb for other reasons. I will try removing non-address bits purely in lldb and see how it compares.

[labath]

In D118794#3290552, @DavidSpickett wrote:

Also if anyone does know how or if debugserver handles this situation, that would be good to know.

I don't know about debugserver, but it would definitely be interesting to check what gdb(server) does here. If it's doing this clientside, then sooner or later somebody will come along wanting to add gdbserver compatibility, and we'll end up doing it in both places.

One side-effect of doing it server-side is that this would interfere with our memory caching code, and we could end up re-reading the same piece of memory (with different tags) multiple times. May not make a big difference in practice, but I think it's a sign that this is done at the wrong level.

Doing this at the level of Target/Process::ReadMemory should still be fairly centralized, and it would not interfere with caching.

[DavidSpickett]

check what gdb(server) does here

Will do.

One side-effect of doing it server-side is that this would interfere with our memory caching code

Yes I also wanted to fix the memory cache in lldb but you're right it needs the same logic applying and no point doing it twice if we don't need to. I'm working on changes to the lldb side instead now.

[DavidSpickett]

Switch to removing non-address bits in lldb instead of lldb-server.

The breakpoint issues I mention only really happen if you try to break on a tagged
function pointer. Which is pretty niche, but I hope to address it later anyway.

On the issue of whether to use FixData vs FixCode there's 2 maybe 3 ways to go:

• Assume that they're the same, which does work for Linux, for now.
• Add a method that does both fixes, on the assumption that the virtual address size for code and data is the same so no harm done and all bits will be removed either way.
• Extensively track whether addresses refer to code or data. In some situations this is possible (looking at the exec bits of a memory mapping for example) but I don't have a great idea what that looks like at this time.

Option 2 seems like a good way to go for now.

[DavidSpickett]

Check that the "expression" command also treats pointers as equivalent.

[omjavaid]

In D118794#3405724, @DavidSpickett wrote:

Switch to removing non-address bits in lldb instead of lldb-server.

The breakpoint issues I mention only really happen if you try to break on a tagged
function pointer. Which is pretty niche, but I hope to address it later anyway.

On the issue of whether to use FixData vs FixCode there's 2 maybe 3 ways to go:

• Assume that they're the same, which does work for Linux, for now.
• Add a method that does both fixes, on the assumption that the virtual address size for code and data is the same so no harm done and all bits will be removed either way.
• Extensively track whether addresses refer to code or data. In some situations this is possible (looking at the exec bits of a memory mapping for example) but I don't have a great idea what that looks like at this time.

Option 2 seems like a good way to go for now.

So on the topic of separate code/data address masks (Linux specific). I dont recall if the actual position of the mask in the address changes or not? It may be the case that we have separate code and address masks but their position in the address bits is fixed for both. Which will mean we actually dont need two separate functions. I tried fidning it out in Linux documentation but it only says "Separate masks are exposed for data pointers and instruction pointers". It doesnt specifically says if the location of the both can be different or not.
Do you have any explanation on this from AARM

[DavidSpickett]

Do you have any explanation on this from AARM

Yes I do.

linux arch/arm64/kernel/ptrace.c:
  /*
   * The PAC bits can differ across data and instruction pointers
   * depending on TCR_EL1.TBID*, which we may make use of in future, so
   * we expose separate masks.
   */
  unsigned long mask = ptrauth_user_pac_mask();
  struct user_pac_mask uregs = {
    .data_mask = mask,
    .insn_mask = mask,
  };

So currently we'll only ever see one value, in both masks. The control bit this refers to is:

D13.2.131 TCR_EL1, Translation Control Register (EL1)

TBID0, bit [51]

0b0 TCR_EL1.TBI0 applies to Instruction and Data accesses.
0b1 TCR_EL1.TBI0 applies to Data accesses only.

This is talked about earlier in the docs:

Supported PAC field and relation to the use of address tagging

When address tagging is used
The PAC field is Xn[54:bottom_PAC_bit].

When address tagging is not used
The PAC field is Xn[63:56, 54:bottom_PAC_bit].

The upshot of that is that you could have top byte ignore and PAC for data, but only PAC for instruction addresses.

PAC itself is all or nothing, at the hardware level it's on or off. If you wanted to not use it for one of code or data
your runtime simply chooses not to sign any pointers. Like arm64e appears to do for data
(https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication).

The current masks that lldb shows, which have top byte ignore included already:

(lldb) process status --verbose
<...>
Addressable code address mask: 0xff7f000000000000
Addressable data address mask: 0xff7f000000000000

So the end result is the same for us. What could happen is a future extension that isn't top byte ignore could use
those bits instead of PAC, making the PAC specific mask 0x007f...

Though I don't know how Linux would reconsile enabling TBI for userspace then doing that. Maybe the amount of top byte
use is small enough it could be changed (especially top byte of code addresses). But chances are slim it seems to me.

So back to my ideas in the previous comment.

Assume that they're the same, which does work for Linux, for now.

Would work fine for Linux for now and probably for a long time given that changing the TBI setting would be seen as an ABI issue.
And if someone decided to disable TBI completely and only use PAC, this still works because PAC extends into the top byte.

If they do decide to disable TBI for instructions then we're still fine given that the mask to extract the virtual address remains
the same. Yes the PAC mask has changed but the debugger is looking to remove *all* non-address bits.

E.g. If we disable TBI for instruction accesses the mask is 0xff7f000000000000 because PAC claims the top byte.
Then the mask for data accesses is 0x007f000000000000 but we add TBI to get 0xff7f000000000000. Same result in the end.

So we could just pick one of the methods and standardise on that for sitautions where you don't know for sure it'll be a code address.
This will have to be FixDataAddress due to Arm Thumb's mode bit 0. We don't want to be aligning all reads to 2 bytes.
(FWIW this matches what I've done so far, though that was unintentional)

Perhaps we add a third method to make that clear (name subject to change) FixAnyAddress. Then the Arm code can forward that to fixdata and AArch64
can pick either data or code. For situations where you're sure you can pick code or data e.g. code breakpoint on an address.

Add a method that does both fixes, on the assumption that the virtual address size for code and data is the same so no harm done and all bits will be removed either way.

The Arm Thumb problem means this is not going to work. (not that those targets are likely to care about non-address bits but these Fix calls are made from generic code
so it does still matter)

Extensively track whether addresses refer to code or data

Isn't realistic a lot of the time. Though there are some clear situations where FixCode or FixData makes more sense so we can do some of this, just not an lldb wide tracking
framework sort of thing.

So my suggestion for a solution would be to add a FixAnyAddress alongside FixCode and FixData, and use that whenever it could be either. Tricky things like Arm Thumb can
then choose what the most "safe" fix is.

Tell me if that logic makes sense.

Which will mean we actually dont need two separate functions.

At the ABI plugin level we do simply due to Arm Thumb existing. Lower down yeah you could get away with reading just one of the PAC masks but it's not much of a saving.

[omjavaid]

Thanks for good detailed explanation. I think from the code readability point of view, we may use FixAddress function which i believe already exists in ABI and if not then introduce FixAnyAddress may be. We can put all the comments about PAC/TBI code vs data address bits there in AArch64 ABI code instead of putting a comment about code/data address everytime we use FixDataAddress in generic code.

[DavidSpickett]

Cool. I will apply this to existing code first, in another change.

[DavidSpickett]

Use FixAnyAddress instead of FixDataAddress.

[DavidSpickett]

Correct "addr" -> "fixed_addr" in a couple of comments.

lldb/source/Target/Process.cpp

Status Process::DisableSoftwareBreakpoint(BreakpointSite *bp_site) {
   return error;
 }
 
 // Uncomment to verify memory caching works after making changes to caching
 // code
 //#define VERIFY_MEMORY_READS
 
 size_t Process::ReadMemory(addr_t addr, void *buf, size_t size, Status &error) {
+  if (ABISP abi_sp = GetABI())
+    addr = abi_sp->FixAnyAddress(addr);
+
   error.Clear();
   if (!GetDisableMemoryCache()) {
 #if defined(VERIFY_MEMORY_READS)
     // Memory caching is enabled, with debug verification
 
     if (buf && size) {
       // Uncomment the line below to make sure memory caching is working.
       // I ran this through the test suite and got no assertions, so I am
size_t Process::ReadCStringFromMemory(addr_t addr, char *dst,
   }
   return total_cstr_len;
 }
 
 size_t Process::ReadMemoryFromInferior(addr_t addr, void *buf, size_t size,
                                        Status &error) {
   LLDB_SCOPED_TIMER();
 
+  if (ABISP abi_sp = GetABI())
+    addr = abi_sp->FixAnyAddress(addr);
+
   if (buf == nullptr || size == 0)
     return 0;
 
   size_t bytes_read = 0;
   uint8_t *bytes = (uint8_t *)buf;
 
   while (bytes_read < size) {
     const size_t curr_size = size - bytes_read;
while (bytes_written < size) {
     if (curr_bytes_written == curr_size || curr_bytes_written == 0)
       break;
   }
   return bytes_written;
 }
 
 size_t Process::WriteMemory(addr_t addr, const void *buf, size_t size,
                             Status &error) {
+  if (ABISP abi_sp = GetABI())
+    addr = abi_sp->FixAnyAddress(addr);
+
 #if defined(ENABLE_MEMORY_CACHING)
   m_memory_cache.Flush(addr, size);
 #endif
 
   if (buf == nullptr || size == 0)
     return 0;
 
   m_mod_id.BumpMemoryID();

lldb/source/Target/ProcessTrace.cpp

 //===-- ProcessTrace.cpp --------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "lldb/Target/ProcessTrace.h"
 
 #include <memory>
 
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
+#include "lldb/Target/ABI.h"
 #include "lldb/Target/SectionLoadList.h"
 #include "lldb/Target/Target.h"
 
 using namespace lldb;
 using namespace lldb_private;
 
 llvm::StringRef ProcessTrace::GetPluginDescriptionStatic() {
   return "Trace process plug-in.";

 }
 
 void ProcessTrace::RefreshStateAfterStop() {}
 
 Status ProcessTrace::DoDestroy() { return Status(); }
 
 size_t ProcessTrace::ReadMemory(addr_t addr, void *buf, size_t size,
                                 Status &error) {
+  if (const ABISP &abi = GetABI())
+    addr = abi->FixAnyAddress(addr);
+
   // Don't allow the caching that lldb_private::Process::ReadMemory does since
   // we have it all cached in the trace files.
   return DoReadMemory(addr, buf, size, error);
 }
 
 void ProcessTrace::Clear() { m_thread_list.Clear(); }
 
 void ProcessTrace::Initialize() {

lldb/source/Target/Target.cpp

size_t Target::ReadMemoryFromFileCache(const Address &addr, void *dst,
   return 0;
 }
 
 size_t Target::ReadMemory(const Address &addr, void *dst, size_t dst_len,
                           Status &error, bool force_live_memory,
                           lldb::addr_t *load_addr_ptr) {
   error.Clear();
 
+  Address fixed_addr = addr;
+  if (ProcessIsValid())
+    if (const ABISP &abi = m_process_sp->GetABI())
+      fixed_addr.SetLoadAddress(abi->FixAnyAddress(addr.GetLoadAddress(this)),
+                                this);
+
   // if we end up reading this from process memory, we will fill this with the
   // actual load address
   if (load_addr_ptr)
     *load_addr_ptr = LLDB_INVALID_ADDRESS;
 
   size_t bytes_read = 0;
 
   addr_t load_addr = LLDB_INVALID_ADDRESS;
   addr_t file_addr = LLDB_INVALID_ADDRESS;
   Address resolved_addr;
-  if (!addr.IsSectionOffset()) {
+  if (!fixed_addr.IsSectionOffset()) {
     SectionLoadList &section_load_list = GetSectionLoadList();
     if (section_load_list.IsEmpty()) {
       // No sections are loaded, so we must assume we are not running yet and
       // anything we are given is a file address.
-      file_addr = addr.GetOffset(); // "addr" doesn't have a section, so its
-                                    // offset is the file address
+      file_addr =
+          fixed_addr.GetOffset(); // "fixed_addr" doesn't have a section, so
+                                  // its offset is the file address
       m_images.ResolveFileAddress(file_addr, resolved_addr);
     } else {
       // We have at least one section loaded. This can be because we have
       // manually loaded some sections with "target modules load ..." or
       // because we have have a live process that has sections loaded through
       // the dynamic loader
-      load_addr = addr.GetOffset(); // "addr" doesn't have a section, so its
-                                    // offset is the load address
+      load_addr =
+          fixed_addr.GetOffset(); // "fixed_addr" doesn't have a section, so
+                                  // its offset is the load address
       section_load_list.ResolveLoadAddress(load_addr, resolved_addr);
     }
   }
   if (!resolved_addr.IsValid())
-    resolved_addr = addr;
+    resolved_addr = fixed_addr;
 
   // If we read from the file cache but can't get as many bytes as requested,
   // we keep the result around in this buffer, in case this result is the
   // best we can do.
   std::unique_ptr<uint8_t[]> file_cache_read_buffer;
   size_t file_cache_bytes_read = 0;
 
   // Read from file cache if read-only section.

lldb/test/API/linux/aarch64/non_address_bit_memory_access/Makefile

+C_SOURCES := main.c
+CFLAGS_EXTRAS := -march=armv8.5-a+memtag
+
+include Makefile.rules

lldb/test/API/linux/aarch64/non_address_bit_memory_access/TestAArch64LinuxNonAddressBitMemoryAccess.py

+"""
+Test that lldb removes non-address bits in situations where they would cause
+failures if not removed. Like when reading memory. Tests are done at command
+and API level because commands may remove non-address bits for display
+reasons which can make it seem like the operation as a whole works but at the
+API level it won't if we don't remove them there also.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class AArch64LinuxNonAddressBitMemoryAccessTestCase(TestBase):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    NO_DEBUG_INFO_TESTCASE = True
+
+    def setup_test(self):
+        if not self.isAArch64PAuth():
+            self.skipTest('Target must support pointer authentication.')
+
+        self.build()
+        self.runCmd("file " + self.getBuildArtifact("a.out"), CURRENT_EXECUTABLE_SET)
+
+        lldbutil.run_break_set_by_file_and_line(self, "main.c",
+            line_number('main.c', '// Set break point at this line.'),
+            num_expected_locations=1)
+
+        self.runCmd("run", RUN_SUCCEEDED)
+
+        if self.process().GetState() == lldb.eStateExited:
+            self.fail("Test program failed to run.")
+
+        self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+            substrs=['stopped',
+                     'stop reason = breakpoint'])
+
+    def check_cmd_read_write(self, write_to, read_from, data):
+        self.runCmd("memory write {} {}".format(write_to, data))
+        self.expect("memory read {}".format(read_from),
+                substrs=[data])
+
+    @skipUnlessArch("aarch64")
+    @skipUnlessPlatform(["linux"])
+    def test_non_address_bit_memory_read_write_cmds(self):
+        self.setup_test()
+
+        # Writes should be visible through either pointer
+        self.check_cmd_read_write("buf", "buf", "01 02 03 04")
+        self.check_cmd_read_write("buf_with_non_address", "buf_with_non_address", "02 03 04 05")
+        self.check_cmd_read_write("buf", "buf_with_non_address", "03 04 05 06")
+        self.check_cmd_read_write("buf_with_non_address", "buf", "04 05 06 07")
+
+        # Printing either should get the same result
+        self.expect("expression -f hex -- *(uint32_t*)buf", substrs=["0x07060504"])
+        self.expect("expression -f hex -- *(uint32_t*)buf_with_non_address",
+                    substrs=["0x07060504"])
+
+    def get_ptr_values(self):
+        frame  = self.process().GetThreadAtIndex(0).GetFrameAtIndex(0)
+        buf = frame.FindVariable("buf").GetValueAsUnsigned()
+        buf_with_non_address = frame.FindVariable("buf_with_non_address").GetValueAsUnsigned()
+        return buf, buf_with_non_address
+
+    def check_api_read_write(self, write_to, read_from, data):
+        error = lldb.SBError()
+        written = self.process().WriteMemory(write_to, data, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(len(data), written)
+        buf_content = self.process().ReadMemory(read_from, 4, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(data, buf_content)
+
+    @skipUnlessArch("aarch64")
+    @skipUnlessPlatform(["linux"])
+    def test_non_address_bit_memory_read_write_api_process(self):
+        self.setup_test()
+        buf, buf_with_non_address = self.get_ptr_values()
+
+        # Writes are visible through either pointer
+        self.check_api_read_write(buf, buf, bytes([0, 1, 2, 3]))
+        self.check_api_read_write(buf_with_non_address, buf_with_non_address, bytes([1, 2, 3, 4]))
+        self.check_api_read_write(buf, buf_with_non_address, bytes([2, 3, 4, 5]))
+        self.check_api_read_write(buf_with_non_address, buf, bytes([3, 4, 5, 6]))
+
+        # Now check all the "Read<type>FromMemory" don't fail
+        error = lldb.SBError()
+        # Last 4 bytes are just for the pointer read
+        data = bytes([0x4C, 0x4C, 0x44, 0x42, 0x00, 0x12, 0x34, 0x56])
+        written = self.process().WriteMemory(buf, data, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(len(data), written)
+
+        # C string
+        c_string = self.process().ReadCStringFromMemory(buf_with_non_address, 5, error)
+        self.assertTrue(error.Success())
+        self.assertEqual("LLDB", c_string)
+
+        # Unsigned
+        unsigned_num = self.process().ReadUnsignedFromMemory(buf_with_non_address, 4, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(0x42444c4c, unsigned_num)
+
+        # Pointer
+        ptr = self.process().ReadPointerFromMemory(buf_with_non_address, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(0x5634120042444c4c, ptr)
+
+    @skipUnlessArch("aarch64")
+    @skipUnlessPlatform(["linux"])
+    def test_non_address_bit_memory_read_write_api_target(self):
+        self.setup_test()
+        buf, buf_with_non_address = self.get_ptr_values()
+
+        # Target only has ReadMemory
+        error = lldb.SBError()
+        data = bytes([1, 2, 3, 4])
+        written = self.process().WriteMemory(buf, data, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(len(data), written)
+
+        addr = lldb.SBAddress()
+        addr.SetLoadAddress(buf, self.target())
+        buf_read = self.target().ReadMemory(addr, 4, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(data, buf_read)
+
+        addr.SetLoadAddress(buf_with_non_address, self.target())
+        buf_non_address_read = self.target().ReadMemory(addr, 4, error)
+        self.assertTrue(error.Success())
+        self.assertEqual(data, buf_non_address_read)
+
+        # Read<type>FromMemory are in Target but not SBTarget so no tests for those.
+
+    @skipUnlessArch("aarch64")
+    @skipUnlessPlatform(["linux"])
+    def test_non_address_bit_memory_caching(self):
+        # The read/write tests above do exercise the cache but this test
+        # only cares that the cache sees buf and buf_with_non_address
+        # as the same location.
+        self.setup_test()
+        buf, buf_with_non_address = self.get_ptr_values()
+
+        # Enable packet logging so we can see when reads actually
+        # happen.
+        log_file = self.getBuildArtifact("lldb-non-address-bit-log.txt")
+        # This defaults to overwriting the file so we don't need to delete
+        # any existing files.
+        self.runCmd("log enable gdb-remote packets -f '%s'" % log_file)
+
+        # This should fill the cache by doing a read of buf_with_non_address
+        # with the non-address bits removed (which is == buf).
+        self.runCmd("p buf_with_non_address")
+        # This will read from the cache since the two pointers point to the
+        # same place.
+        self.runCmd("p buf")
+
+        # Open log ignoring utf-8 decode errors
+        with open(log_file, 'r', errors='ignore') as f:
+            read_packet = "send packet: $x{:x}"
+            read_buf_packet = read_packet.format(buf)
+            read_buf_with_non_address_packet = read_packet.format(buf_with_non_address)
+
+            # We expect to find 1 and only 1 read of buf.
+            # We expect to find no reads using buf_with_no_address.
+            found_read_buf = False
+            for line in f:
+                if read_buf_packet in line:
+                    if found_read_buf:
+                        self.fail("Expected 1 read of buf but found more than one.")
+                    found_read_buf = True
+
+                if read_buf_with_non_address_packet in line:
+                    self.fail("Unexpected read of buf_with_non_address found.")
+
+            if not found_read_buf:
+                self.fail("Did not find any reads of buf.")

lldb/test/API/linux/aarch64/non_address_bit_memory_access/main.c

+#include <linux/mman.h>
+#include <sys/mman.h>
+#include <unistd.h>
+
+int main(int argc, char const *argv[]) {
+  size_t page_size = sysconf(_SC_PAGESIZE);
+  // Note that we allocate memory here because if we used
+  // stack or globals lldb might read it in the course of
+  // running to the breakpoint. Before the test can look
+  // for those reads.
+  char *buf = mmap(0, page_size, PROT_READ | PROT_WRITE,
+                   MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+  if (buf == MAP_FAILED)
+    return 1;
+
+#define sign_ptr(ptr) __asm__ __volatile__("pacdza %0" : "=r"(ptr) : "r"(ptr))
+
+  // Set top byte to something.
+  char *buf_with_non_address = (char *)((size_t)buf | (size_t)0xff << 56);
+  sign_ptr(buf_with_non_address);
+  // Address is now:
+  // <8 bit top byte tag><pointer signature><virtual address>
+
+  return 0; // Set break point at this line.
+}