[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 ...
[lldb-vscode] redirect stderr/stdout to the IDE's consoleIn certain occasions times, like when LLDB is initializing andevaluating the .lldbinit files, it tries to print to stderr and stdoutdirect
[lldb-vscode] redirect stderr/stdout to the IDE's consoleIn certain occasions times, like when LLDB is initializing andevaluating the .lldbinit files, it tries to print to stderr and stdoutdirectly. This confuses the IDE with malformed data, as it talks tolldb-vscode using stdin and stdout following the JSON RPC protocol. Thisends up terminating the debug session with the user unaware of what'sgoing on. There might be other situations in which this can happen, andthey will be harder to debug than the .lldbinit case.After several discussions with @clayborg, @yinghuitan and @aadsm, werealized that the best course of action is to simply redirect stdout andstderr to the console, without modifying LLDB itself. This will prove tobe resilient to future bugs or features.I made the simplest possible redirection logic I could come up with. Itonly works for POSIX, and to make it work with Windows should be merelychanging pipe and dup2 for the windows equivalents like _pipe and _dup2.Sadly I don't have a Windows machine, so I'll do it later once my officereopens, or maybe someone else can do it.I'm intentionally not adding a stop-redirecting logic, as I don't see ituseful for the lldb-vscode case (why would we want to do that, really?).I added a test.Note: this is a simpler version of D80659. I first tried to implement aRIIA version of it, but it was problematic to manage the state of thethread and reverting the redirection came with some non trivialcomplexities, like what to do with unflushed data after the debugsession has finished on the IDE's side.
[lldb] Use assertIn/NotIn over assertTrue/False (NFC)For improved failure messages, use `assertIn` over `assertTrue`.Differential Revision: https://reviews.llvm.org/D96095
[lldb] Convert assertTrue(a == b) to assertEqual(a, b)Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.These were mostly done via regex search & replace, wit
[lldb] Convert assertTrue(a == b) to assertEqual(a, b)Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.These were mostly done via regex search & replace, with some manual fixes.Differential Revision: https://reviews.llvm.org/D95813
Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request.Summary: The IDE has no packets that are sent to lldb-vscode that say which thread and frame are s
Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request.Summary: The IDE has no packets that are sent to lldb-vscode that say which thread and frame are selected. The only way we know is we get a request for variables for a stack frame via a "scopes" request. When we receive this packet we make that thread and frame the selected thread and frame in lldb. This way when people execute lldb commands in the debug console by prefixing the expression with the backtick character, we will have the right thread and frame selected. Previously this was not updated as new stack frames were selected.Reviewers: labath, aadsm, wallace, JDevlieghereSubscribers: lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D77347