[Lldb-commits] [PATCH] D105180: [lldb][AArch64] Add memory tag writing to lldb-server

David Spickett via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Jul 23 06:53:23 PDT 2021


DavidSpickett added inline comments.


================
Comment at: lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py:56
         # Run the packet stream
         context = self.expect_gdbremote_sequence()
         self.assertIsNotNone(context)
----------------
omjavaid wrote:
> omjavaid wrote:
> > DavidSpickett wrote:
> > > omjavaid wrote:
> > > > 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.
> > > 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?
> > 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
> > 
> @DavidSpickett  any update on above issue?
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.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105180/new/

https://reviews.llvm.org/D105180



More information about the lldb-commits mailing list