[lldb] Delete more mydir references (NFC)
Support logpoints in lldb-vscodeThis patch implements VSCode DAP logpoints feature (also called tracepointin other VS debugger).This will provide a convenient way for user to do printf style logg
Support logpoints in lldb-vscodeThis patch implements VSCode DAP logpoints feature (also called tracepointin other VS debugger).This will provide a convenient way for user to do printf style loggingdebugging without pausing debuggee.Differential Revision: https://reviews.llvm.org/D127702
show more ...
[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
[source maps] fix source mapping when there are multiple matching rulesD104406 introduced an error in which, if there are multiple matchings rules for a given path, lldb was only checking for the v
[source maps] fix source mapping when there are multiple matching rulesD104406 introduced an error in which, if there are multiple matchings rules for a given path, lldb was only checking for the validity in the filesystem of the first match instead of looking exhaustively one by one until a valid file is found.Besides that, a call to consume_front was being done incorrectly, as it was modifying the input, which renders subsequent matches incorrect.I added a test that checks for both cases.Differential Revision: https://reviews.llvm.org/D106723
[lldb] [test] Workaround symlink-related test failuresUse realpath() when spawning the executable create_after_attachto workaround a FreeBSD plugin (and possibly others) problem.If the executable
[lldb] [test] Workaround symlink-related test failuresUse realpath() when spawning the executable create_after_attachto workaround a FreeBSD plugin (and possibly others) problem.If the executable is started via a path containing a symlink, it isadded to the module list twice -- via the real and apparent path.This in turn cases the requested breakpoint to resolve twice.Use realpath() for main program path in lldb-vscode breakpoint teststo workaround a similar problem. If the passed path does not matchthe realpath, lldb-vscode does not report the breakpoints as verifiedand causes tests to fail.Since the underlying problems are non-trivial to fix and the purposeof these tests is not to reproduce symlink problems, let's applytrivial workarounds to make them pass.Differential Revision: https://reviews.llvm.org/D97230
[lldb] Use assertIn/NotIn over assertTrue/False (NFC)For improved failure messages, use `assertIn` over `assertTrue`.Differential Revision: https://reviews.llvm.org/D96095
[lldb] [test] Update test status for NetBSD
[lldb] [test] Link FreeBSD test failures to bugsDifferential Revision: https://reviews.llvm.org/D92740
[lldb] [test] Update XFAILs/skips for FreeBSDUpdate expected failures and test skips based on common resultsfor the old and new FreeBSD plugins.
[lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To clear all breakpoint for a source, specify an emp
[lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To clear all breakpoint for a source, specify an empty array.`However, leaving the breakpoints field unset is also a well formed request (note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's unset, we have a couple choices:1. Crash (current behavior)2. Clear breakpoints3. Return an error response that the breakpoints field is missing.I propose we do (2) instead of (1), and treat an unset breakpoints field the same as an empty breakpoints field.[1] https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpointsReviewed By: wallace, labathDifferential Revision: https://reviews.llvm.org/D88513
[lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints requestSummary:When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved,
[lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints requestSummary:When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved, weneed to use a query similar to what CommandObjectSource::DumpLinesInSymbolContexts does, which is the logicused by the CLI to display the source line at a given breakpoint. That's necessary because from a breakpointlocation you only have an address, which points to the original source location, not the source mapped one.in the setBreakpoints request handler, we haven't been doing such query and we were returning the originalsource location, which was breaking the UX of VSCode, as many breakpoints were being set but not displayedin the source file next to each line. Besides, clicking the source path of a breakpoint in the breakpointsview in the debug tab was not working for this case, as VSCode was trying to open a non-existent file, thusshowing an error to the user.Ideally, we should do the query mentioned above to find the actual source location to respond to the IDE,however, that query is expensive and users can have an arbitrary number of breakpoints set. As a simpler fix,the request sent by VSCode already contains the full source path, which exists because the user set it fromthe IDE itself, so we can simply reuse it instead of querying from the SB API.I wrote a test for this, and found out that I had to move SetSourceMapFromArguments after RunInitCommands inlldb-vscode.cpp, because an init command used in all tests is `settings clear -all`, which would clear thesource map unless specified after initCommands. And in any case, I think it makes sense to have initCommandsrun before anything the debugger would do.Reviewers: clayborg, kusmour, labath, aadsmSubscribers: lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D76968
[lldb] NFC: Fix trivial typo in comments, documents, and messagesDifferential Revision: https://reviews.llvm.org/D77460
[lldb-vscode] fix breakpoint result orderingSummary:The DAP specifies the following for the SetBreakpoints request: The breakpoints returned are in the same order as the elements of the 'breakp
[lldb-vscode] fix breakpoint result orderingSummary:The DAP specifies the following for the SetBreakpoints request: The breakpoints returned are in the same order as the elements of the 'breakpoints' argumentsThis was not followed, as lldb-vscode was returning the breakpoints in a different order, because they were first stored into a map, and then traversed. Of course, maps normally don't preserve ordering.See this log I captured: --> {"command":"setBreakpoints", "arguments":{ "source":{ "name":"main.cpp", "path":"/Users/wallace/fbsource/xplat/sand/test-projects/buck-cpp/main.cpp" }, "lines":[6,10,11], "breakpoints":[{"line":6},{"line":10},{"line":11}], "sourceModified":false }, "type":"request", "seq":3 } <-- {"body":{ "breakpoints":[ {"id":1, "line":11,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true}, {"id":2,"line":6,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true}, {"id":3,"line":10,"source":{"name":"main.cpp","path":"xplat/sand/test-projects/buck-cpp/main.cpp"},"verified":true}]}, "command":"setBreakpoints", "request_seq":3, "seq":0, "success":true, "type":"response" }As you can see, the order was not respected. This was causing the IDE not to be able to disable/enable breakpoints by clicking on them in the breakpoint view in the lower corner of the Debug tab.This diff fixes the ordering problem. The traversal + querying was done very fast in O(nlogn) time. I'm keeping the same complexity.I also updated a couple of tests to account for the ordering.Reviewers: clayborg, aadsm, kusmour, labathSubscribers: lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D76891
[lldb/Test] s/skipIfDarwinEmbedded/skipIfRemote/ in VSCode tests.As pointed out on lldb-commits this skipIfRemote is the better fit forthe decorator.
[lldb/Test] Skip VSCode test on embedded DarwinThese tests are not configured to run on the device.
[lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suiteSummary:The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely usel
[lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suiteSummary:The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely useless for actually debugging the issue.This patch is just replacing this construct (and similar ones like `assertTrue(a != b, ...)` with the proper call to assertEqual or assertNotEquals.This patch was mostly written by a shell script with some manual verification afterwards:```lang=pythonimport sysdef sanitize_line(line): if line.strip().startswith("self.assertTrue(") and " == " in line: line = line.replace("self.assertTrue(", "self.assertEquals(") line = line.replace(" == ", ", ", 1) if line.strip().startswith("self.assertTrue(") and " != " in line: line = line.replace("self.assertTrue(", "self.assertNotEqual(") line = line.replace(" != ", ", ", 1) return linefor a in sys.argv[1:]: with open(a, "r") as f: lines = f.readlines() with open(a, "w") as f: for line in lines: f.write(sanitize_line(line))```Reviewers: labath, JDevlieghereReviewed By: labathSubscribers: abidh, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D74475
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdi
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151