This was removed here rL366590 by accident.
Thanks for restoring this, but I'm a bit confused how this has happened. My original diff didn't remove these folders, but it seems when I committed the diff via arcanist and git llvm it also removed these other folders. I assume git llvm is when translating the change to SVN not just removing a folder but also all folders in the same directory?
Interesting.. I wouldn't be totally surprised by that as git-llvm does some magic to svn check out only the files/directories that have been modified. Combining that with the different treatment of directories in svn and git (explicit modelling vs. implicit "it exists if it contains a file"), I can see how things might go south in some corner cases like this. But that's just speculation -- I'm generally trying to avoid git-llvm as it is too magical for my taste. Maybe @jyknight or @mehdi_amini can shed more light on this?
I was glad the vscode testcases are gone as they are racy causing many false failures on our Fedora buildbot always hanging until the whole testsuite gets killed:
1910 ? Sl 0:00 | \_ /usr/bin/python /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/lldb-test-traces --build-dir /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/./bin/lldb --dsymutil /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/./bin/dsymutil --filecheck /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/./bin/FileCheck -C /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --env LLVM_LIBS_DIR=/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/./lib /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint -p TestVSCode_setBreakpoints.py 2649 ? Sl 0:00 | \_ /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/bin/lldb-vscode 2690 ? S 0:00 | \_ /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/bin/lldb-server gdbserver --fd=9 --native-regs --setsid 2708 ? t 0:00 | \_ /home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/build/lldb-test-build.noindex/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.test_functionality/a.out
I have checked the lldb-vscode server does print:
But then lldb itself waits forever for the breakpoint hit, unaware why so far. The problem debugging it is that it happens only on slow hosts where it is difficult to run the testsuite on LLDB built with full DWARF.
If someone has an idea, otherwise we (with @kwk) will continue debugging it.
It is hanging in vscode.py function recv_packet somehow despite the packet type=event event=stopped is received by the other Python thread (and put into recv_packets) it somehow never quits the loop.
@Hui what do you mean? the history is still there:
$ git log lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py commit a61c247ce189efe7641dccb8ad7f85f60fc72220 (master) Author: Antonio Afonso <firstname.lastname@example.org> Date: Mon Jul 22 23:35:05 2019 +0000 Restore tests for lldb-server and lldb-vscode removed at rL366590 commit b45853f173139c7c3078b97f53e7a6eba6148c13 Author: Raphael Isemann <email@example.com> Date: Fri Jul 19 15:55:23 2019 +0000 [lldb][NFC] Cleanup mentions and code related to lldb-mi commit 08c38f77c5fb4d3735ec215032fed8ee6730b3db Author: Pavel Labath <firstname.lastname@example.org> Date: Mon Jul 1 12:41:20 2019 +0000 Revert "Implement xfer:libraries-svr4:read packet" ...