Proto commits in googlestadia/vsi-lldb

These 17 commits are when the Protocol Buffers files have changed:

2022-09-21

[lldb-api] Use SbProcess::Detach(bool keep_stopped) instead of SbProcess::Detach Use the Detach version that explicitly tells whether the process we are detaching from should stay stopped. GitOrigin-RevId: ec22a771b7ca827cd82fccb7d11993c1c11cef80

The documentation is generated from this commit.

2022-09-20

[lldb-api] Extend StopReason mapping to LLDB v14 New StopReasons include ProcessorTrace, Fork, VFork, VForkDone. This change covers extension of cpp/csharp API, mapping and corresponding comments changes. GitOrigin-RevId: 43653145a0ec91fdd223ec259602673f4912e3dc

2022-05-10

[modules] Update the visual studio modules window when lldb tells us to We now listen for the MODULE_LOAD and MODULE_UNLOAD events, and update the module list. This causes VS to reload the module window, which keeps it accurate with respect to the modules loaded on the gamelet. GitOrigin-RevId: 1f1444b1140c49a4970d3172bdda94df13d28208

2022-03-17

[natvis] Implement gRPC for expression compilation This CL is a part of efforts to support Priority attribute. Expressions in Natvis are evaluated as encountered. With this change it will be possible to pre-compile Natvis expressions during visualizer selection process. The current idea is to use it for properly selecting the visualizer, but in the future this could also be used to re-use compiled expressions while evaluating Natvis. GitOrigin-RevId: c238520553e837c0828bf2e8709f4b3663ef7a11

2022-03-07

[debugger] Remove `JumpToLine` method (unused) GitOrigin-RevId: d99b3228bbb5c42a93163a4649b213510ff16bb0

[debugger] Enable setting PC to an arbirarty address The main change in this CL is using `SBFrame::SetPC(addr)` to move the execution pointer instead of resolving the line number and using `JumpToLine`. This enables jumping to an arbitrary address. Simplify the checks in `CanSetNextStatement` -- do the sanity check for the current thread and then compare PC/function name. If the function names are different, return `S_FALSE`, which will make Visual Studio to show a dialog "Are you sure you want to jump to a different function?". `CanSetNextStatement` is no longer called from `SetNextStatement`, since Visual Studio will always call it beforehand (and also handle the case of jumping to a different function). Several other things are fixed along the way: * Move the function name resolution logic inside the `DebugCodeContext`, because the name needs to be re-resolved after the address changes (e.g. after `Add/Subtract)`. * Merge `DebugMemoryContext` into `DebugCodeContext`. They're basically the same thing and from the implementation perspective it doesn't make a difference if they're two different classes. GitOrigin-RevId: 3de7467b2879a7ceb113fae4b3031bf21043942e

2021-11-18

[Debugger] Merge RemoveModule+AddModule into TryReplaceModule Merges 2 methods into 1 to make it more obvious what's happening in the method. We also pass triple from the module being replaced into the added one (added GetTriple() to SbModule API). GitOrigin-RevId: 58360cd444f2b2237f85b09a4f7037d86f64bcd7

2021-08-20

[grpc-server]: add SaveCore method to gRPC SbProcessApi In order to call `process save-core` method from lldb we need to set up the corresponding gRPC channel. This is the first change in binding VS extension to lldb when generating minidumps on request. GitOrigin-RevId: 8bf0e7aca59a378de25946891e203d5fcbf38832

2021-06-08

[vsi_debug] Fix moving instruction pointer in C++ methods In some cases we pre-process function names (strip args and remove leading colons), and in some cases we return the raw unprocessed function name. This may lead to incorrect comparison of the function names - even though the code belongs to the same function, we compare processed and unprocessed function names and decide that these are two different methods. Function comparison is done by VS before moving the instruction pointer. Incorrect function comparison was the root cause why moving the instruction pointer didn't always work. GitOrigin-RevId: eb3fca20f78baf75fe3a8de7faa3004aee635c8f

2021-05-18

[debugger] Bind a breakpoint when library loaded Subscribe to lldb breakpoint events and bind local breakpoint once a dynamic library is loaded and lldb emits a BreakpointChanged event. GitOrigin-RevId: d9d6c73c5299a494c29f6bfb6c41929a2f01906d

[lldb] Implement static breakpoint api GitOrigin-RevId: 47f1a8c76c5d428f113e6b99f1b5aafda2bcbe1e

2021-05-10

[debugger] Add AddListener API to RemoteTarget GitOrigin-RevId: a98471b19b7ada99b451d13e3370135c27304f3f

2021-04-30

[debugging] Propagate DataFlavour field to SbEvent GitOrigin-RevId: a9786be56dbb4b67021b7267a59851c500b68e2a

2021-04-23

[natvis] Make copies of VariableInformation holding context variables If a Natvis expression is equal to a variable name, LLDB or lldb-eval may return a reference to the variable. Since display value of these expressions are determined after all expression are evaluated, display values of all expressions corresponding to the same variable will be equal to the last value of the variable. The issue arises when the variable's value is changed between two such expressions, which is allowed for custom Natvis variables (<Variable> rule in <CustomListItems>). Consider the following example: <CustomListItems> <Variable Name="counter" InitialValue="0" /> <Loop> <Break Condition="counter == 3" /> <Exec>counter++</Exec> <Item>counter</Item> </Loop> </CustomListItems> The expected output is [1, 2, 3], but due to deferred evaluations of display values, the output is [3, 3, 3]. This CL copies evaluations results of custom Natvis variables (aka. context variables) in order to prevent the issue. GitOrigin-RevId: f9dbb1ec97aa4e8217fde967cc5b0005abc130f4

2021-02-09

vsi-lldb: Better support for context variables in Natvis Natvis' CustomListItems uses LLDB's context (aka. convenience) variables to support Natvis scope <Variable>s. These variables can currently be created only using a slow LLDB.EvaluateExpression method and before this change could only be evaluated using the same method. This CL supports lldb-eval evaluation of expressions that use these variables. It also introduces structures that will be useful for supporting creation of these variables via lldb-eval in the future. GitOrigin-RevId: 547a0fa887e719ed2bf4c206f115129a775e9370

2021-02-02

vsi-lldb: Fix computation of module address in minidumps When replacing a placeholder module with a real module in minidump, we compute the address of the object file from the difference between file address and and file offset in the first code section. However, the LLVM 10 toolchain can create segments with different differences of file address-offset. This CL just replaces the calculation with direct call to SBModule.GetObjectFileHeaderAddress. GitOrigin-RevId: 5d4429c4ca50674579983319fba9ef90071c0165

2020-12-16

Internal change GitOrigin-RevId: eb5e3974bfca31d8e2cb5032281fa708b947ad1c