This is an archive of the discontinued LLVM Phabricator instance.

[lldb][AArch64] Add memory tag writing to lldb-server
ClosedPublic

Authored by DavidSpickett on Jun 30 2021, 3:35 AM.

Details

Summary

This is implemented using the QMemTags packet, as specified
by GDB in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets

(recall that qMemTags was previously added to read tags)

On receipt of a valid packet lldb-server will:

  • align the given address and length to granules (most of the time lldb will have already done this but the specification doesn't guarantee it)
  • Repeat the supplied tags as many times as needed to cover the range. (if tags > range we just use as many as needed)
  • Call ptrace POKEMTETAGS to write the tags.

The ptrace step will loop just like the tag read does,
until all tags are written or we get an error.
Meaning that if ptrace succeeds it could be a partial write.
So we call it again and if we then get an error, return an error to
lldb.

We are not going to attempt to restore tags after a partial
write followed by an error. This matches the behaviour of the
existing memory writes.

The lldb-server tests have been extended to include read and
write in the same test file. With some updated function names
since "qMemTags" vs "QMemTags" isn't very clear when they're
next to each other.

Diff Detail

Event Timeline

DavidSpickett created this revision.Jun 30 2021, 3:35 AM
DavidSpickett requested review of this revision.Jun 30 2021, 3:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2021, 3:35 AM
omjavaid added inline comments.Jul 6 2021, 3:53 AM
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

This test is still not stable given we wait for stop notification while process may have exited. This causes test to hang till timeout expiry.

omjavaid added inline comments.Jul 6 2021, 3:36 PM
lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
1517

We unpack, repeat and then repack. Cant we combine this operation by introducing a function that takes packed tags, repeats them and returns packed tags.

DavidSpickett added inline comments.Jul 7 2021, 3:23 AM
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

Sure, but I don't think there's a better way to do it. Short of reading from a process that's already exited. (which seems to sort of work for memory but tags have weird results so I don't think it's meant to work)

Note that the test file does pause after the print: https://github.com/llvm/llvm-project/blob/main/lldb/test/API/tools/lldb-server/memory-tagging/main.c#L16

We've got a few scenarios:

  • All goes well, we get the print. The test program is in it's delay and we stop it.
  • The test crashes at some point before sending the stop. The test program waits 60s then exits.
  • The test program crashes before printing. The test waits on the print until it times out.
  • The test picks up the print just as the test program is exiting, or has already exited. The test times out waiting for the stop response.

It's not free of timing issues but it means that you won't have either test or test program hanging around if either fails.

What do you think?

DavidSpickett added inline comments.Jul 14 2021, 1:24 AM
lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
1517

I looked into this. There's three functions being used:

  • Unpack
  • Repeat
  • Pack

If I added a combo method to do all three in sequence, you'd still need unpack and pack available individually for other users. Plus this is the only place that will be doing this so yeah it'd make this a bit more neat but you're just moving the code from one place to another.

If the situation comes up a second time, it'll be worth doing.

omjavaid added inline comments.Jul 16 2021, 1:03 AM
lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
1550

This assertion suggests something went wrong on ptrace side. Should we replace it with a simple error return? or you think inferior program should no longer be debugable after such an error?

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
3567

by this you mean packet?

lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

The problem I was facing was lldb-server existed after inferior launch. I have given my configuration below I might be doing something wrong:
LLDB_TEST_COMPILER=/home/omair/work/tools/gcc-linaro-11.0.0-2021.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
LLDB_TEST_ARCH=aarch64

LLDB_PLATFORM_NAME=remote-linux
LLDB_PLATFORM_URL=connect://192.168.53.253:54321
#-u CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy \

$LLDB_BUILD_DIR/bin/lldb-dotest \
-A $LLDB_TEST_ARCH \
-C $LLDB_TEST_COMPILER \
--build-dir $LLDB_BUILD_DIR/lldb-test-build.noindex \
--executable $LLDB_BUILD_DIR/bin/lldb \
--dsymutil $LLDB_BUILD_DIR/bin/dsymutil \
--llvm-tools-dir $LLDB_BUILD_DIR/bin \
--lldb-libs-dir $LLDB_BUILD_DIR/lib \
--platform-name=$LLDB_PLATFORM_NAME \
--platform-url=$LLDB_PLATFORM_URL \
-p $1 $2 $3

omjavaid added inline comments.Jul 23 2021, 2:15 AM
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

@DavidSpickett any update on above issue?

DavidSpickett added inline comments.Jul 23 2021, 6:53 AM
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

If I plug my paths into that script it runs fine for me.

Can you write out what you think is going on? I don't understand what you're seeing and without a way to reproduce myself I'm just guessing. (which are the scenarios I outlined above)

When you run it what's the lifetime of the test, the lldb-server on the remote, the test program it's running. That sort of thing.

omjavaid added inline comments.Jul 25 2021, 11:24 PM
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
56

I think my qemu rootfs is misconfigured may be not sure thought

Log with Dynamically linked executable:
sending packet to remote: $A332,0,2f686f6d652f6f6d6169722f776f726b2f6c6c64622f6c6c64622d6465762f6275696c642f72656c656173652f686f73742f6c6c64622d746573742d6275696c642e6e6f696e6465782f746f6f6c732f6c6c64622d7365727665722f6d656d6f72792d74616767696e672f5465737447646252656d6f74654d656d6f727954616767696e672e746573745f514d656d546167735f7061636b6574735f6c6c67732f612e6f7574#5f
Launched '/home/omair/work/lldb/lldb-dev/build/release/host/lldb-test-build.noindex/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.test_QMemTags_packets_llgs/a.out' as process 32041...
R packet to remote: $OK#9a
sending packet to remote: $qLaunchSuccess#a5
R packet to remote: $OK#9a
sending packet to remote: $c#63
R packet to remote: /lib/ld-linux-aarch64.so.1: No such file or directory

Log with static linked executable:

sending packet to remote: $A332,0,2f686f6d652f6f6d6169722f776f726b2f6c6c64622f6c6c64622d6465762f6275696c642f72656c656173652f686f73742f6c6c64622d746573742d6275696c642e6e6f696e6465782f746f6f6c732f6c6c64622d7365727665722f6d656d6f72792d74616767696e672f5465737447646252656d6f74654d656d6f727954616767696e672e746573745f714d656d546167735f7061636b6574735f6c6c67732f612e6f7574#61
Launched '/home/omair/work/lldb/lldb-dev/build/release/host/lldb-test-build.noindex/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.test_qMemTags_packets_llgs/a.out' as process 439...
R packet to remote: $OK#9a
sending packet to remote: $qLaunchSuccess#a5
R packet to remote: $OK#9a
sending packet to remote: $c#63
R packet to remote: buffer: (nil) page_size: 0x1000

omjavaid accepted this revision.Jul 27 2021, 1:08 AM

@DavidSpickett Lets merge this patch series (if it is working on your desk) but we should add information in LLDB wiki or any other appropriate place about how to reliably test mte feature in absence of hardware on desk.

This revision is now accepted and ready to land.Jul 27 2021, 1:08 AM

Great.

The QEMU testing docs https://lldb.llvm.org/use/qemu-testing.html include MTE options. Apart from having a compatible toolchain there's no difference to SVE.

This revision was landed with ongoing or failed builds.Jul 27 2021, 4:02 AM
This revision was automatically updated to reflect the committed changes.