[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
One further tweak for realpathing filepath to match dyldI missed one place I need to realpath the build artifact path,to make it match the path we get back from dyld.
Update three tests to realpath paths that we compare to dyld pathsI get to my work directory through a symlink, so the pathnames thetests get for their build artifacts etc are via that symlink. T
Update three tests to realpath paths that we compare to dyld pathsI get to my work directory through a symlink, so the pathnames thetests get for their build artifacts etc are via that symlink. Thereare three tests which compare those symlink paths to a directoryreceived from dyld on macOS, which is the actual real pathname.These tests have always failed for me on my dekstop but I finallysat down to figure out why. Easy quick fix.
[lldb] Skip a bunch of tests that shouldn't run remotelySkip a bunch of tests that don't really make sense to run remotely.
Reapply "[lldb/test] Automatically find debug servers to test"This reapplies 7df4eaaa93/D96202, which was reverted due to issues onwindows. These were caused by problems in the computation of the
Reapply "[lldb/test] Automatically find debug servers to test"This reapplies 7df4eaaa93/D96202, which was reverted due to issues onwindows. These were caused by problems in the computation of the liblldbdirectory, which was fixed by D96779.The original commit message was:Our test configuration logic assumes that the tests can be run eitherwith debugserver or with lldb-server. This is not entirely correct,since lldb server has two "personalities" (platform server and debugserver) and debugserver is only a replacement for the latter.A consequence of this is that it's not possible to test the platformbehavior of lldb-server on macos, as it is not possible to get a hold ofthe lldb-server binary.One solution to that would be to duplicate the server configurationlogic to be able to specify both executables. However, that seemsexcessively redundant.A well-behaved lldb should be able to find the debug server on its own,and testing lldb with a different (lldb-|debug)server does not seem veryuseful (even in the out-of-tree debugserver setup, we copy the serverinto the build tree to make it appear "real").Therefore, this patch deletes the configuration altogether and changesthe low-level server retrieval functions to be able to both lldb-serverand debugserver paths. They do this by consulting the "supportexecutable" directory of the lldb under test.Differential Revision: https://reviews.llvm.org/D96202
Revert "[lldb/test] Automatically find debug servers to test"The commit 7df4eaaa937332c0617aa665080533966e2c98a0 appears tobreak the windows bot. Revert while I investigate.
[lldb/test] Automatically find debug servers to testOur test configuration logic assumes that the tests can be run eitherwith debugserver or with lldb-server. This is not entirely correct,since l
[lldb/test] Automatically find debug servers to testOur test configuration logic assumes that the tests can be run eitherwith debugserver or with lldb-server. This is not entirely correct,since lldb server has two "personalities" (platform server and debugserver) and debugserver is only a replacement for the latter.A consequence of this is that it's not possible to test the platformbehavior of lldb-server on macos, as it is not possible to get a hold ofthe lldb-server binary.One solution to that would be to duplicate the server configurationlogic to be able to specify both executables. However, that seemsexcessively redundant.A well-behaved lldb should be able to find the debug server on its own,and testing lldb with a different (lldb-|debug)server does not seem veryuseful (even in the out-of-tree debugserver setup, we copy the serverinto the build tree to make it appear "real").Therefore, this patch deletes the configuration altogether and changesthe low-level server retrieval functions to be able to both lldb-serverand debugserver paths. They do this by consulting the "supportexecutable" directory of the lldb under test.Differential Revision: https://reviews.llvm.org/D96202
[lldb] Treat remote macOS debugging like any other remote darwin platformExtract remote debugging logic from PlatformMacOSX and move it intoPlatformRemoteMacOSX so it can benefit from all the logi
[lldb] Treat remote macOS debugging like any other remote darwin platformExtract remote debugging logic from PlatformMacOSX and move it intoPlatformRemoteMacOSX so it can benefit from all the logic necessary forremote debugging.Until now, remote macOS debugging was treated almost identical to localmacOS debugging. By moving in into its own class, we can have it inheritfrom PlatformRemoteDarwinDevice and all the functionality it provides,such as looking at the correct DeviceSupport directory.rdar://68167374Differential revision: https://reviews.llvm.org/D92452