omjavaid added inline comments.
================
Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1550
+ size_t tags_written = tags_vec.iov_len;
+ assert(tags_written && (tags_written <= num_tags));
+
----------------
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?
================
Comment at:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3567
+
+ // This is bytes here and is unpacked into target specific tags later
+ // We cannot assume that number of bytes == length here because the server
----------------
by this you mean packet?
================
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)
----------------
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
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105180/new/
https://reviews.llvm.org/D105180
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
