| Issue |
180045
|
| Summary |
[lldb] ScriptedFrameProviders show no warnings on programming errors
|
| Labels |
lldb
|
| Assignees |
|
| Reporter |
vogelsgesang
|
Debugging a `ScriptedFrameProvider` is a bit cumbersome, since lldb provides little feedback in case of mistakes.
### Observed behavior
There are two error modes which I am aware of:
** 1 . Arbitrary, non-existing names being acknowledged**
Running `target frame-provider register -C x.y` reports
> successfully registered scripted frame provider 'x.y' for target
and `target frame-provider register` lists it as a frame provider, although that class doesn't even exist.
** 2. Frame provider being completely ignored **
Assume we have the following frame provider (which is missing the `get_description` function):
```
class MyFrameProvider(ScriptedFrameProvider):
def get_frame_at_index(self, index):
return index
```
Registering this frame provider via `target frame-provider register` reports "successfully registered scripted frame provider 'frame_provider.MyFrameProvider' for target" and `target frame-provider list` shows the frame provider.
But running `bt` just silently ignores the frame provider.
(In this example, creating an instance of `MyFrameProvider` fails because the frame provider doesn't override the `@abstractmethod get_description`)
** 3. Backtrace failing**
Let's assume you have a simple no-op frame provider:
```
class MyFrameProvider(ScriptedFrameProvider):
@staticmethod
def get_description():
return "Just forward the frames"
def get_frame_at_index(self, index):
return self.input_frames[index]
```
Again, the stack provider registers fine and is shown in target frame-provider list`.
However, running `bt` will report "error: error displaying backtrace for thread: "0x0001"", with no further information.
This is because `get_frame_at_index` returned an `SBFrame` instead of a `ScriptedFrame`. (Probably, we should support returning `SBFrame`s. But that's a separate issue). But at the very least we should provide some feedback to users that the frame provider returned an unexpected
### Expected / Proposed behavior
We should check as much as possible during `target frame-provider register`. I guess we can at least check that the class exists and that it actually inherits from `ScriptedFrameProvider`?
All other warnings / errors should be surfaced in the `bt` command.
E.g., to fix case "2. Frame provider being completely ignored", we could add a warning to `bt`, something like
```
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
* frame #0: 0x0000555555555bee a.out`greet(frame_ptr=0x000055555556f2b0) at async-task-example.cpp:13:49
frame #1: 0x0000555555555709 a.out`write_output(frame_ptr=0x000055555556f3e0) at async-task-example.cpp:5:13
frame #2: 0x0000555555555d91 a.out`greet(frame_ptr=0x000055555556f2b0) at async-task-example.cpp:10:13
WARNING: Frame provider `MyFrameProvider` was not applied because creating an instance failed:
Method `get_description` missing`
```
For the case "3. Backtrace failing", I think we should still show the backtrace (instead of simply erroring out), but add a warning at the end:
```
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
* frame #0: 0x0000555555555bee a.out`greet(frame_ptr=0x000055555556f2b0) at async-task-example.cpp:13:49
frame #1: 0x0000555555555709 a.out`write_output(frame_ptr=0x000055555556f3e0) at async-task-example.cpp:5:13
frame #2: 0x0000555555555d91 a.out`greet(frame_ptr=0x000055555556f2b0) at async-task-example.cpp:10:13
WARNING: Frame provider `MyFrameProvider` returned an unexpected result type (`SBFrame`) when asked for thread index 1
```
But not sure how to implement this in lldb. Does lldb already have a concept of "warnings" for the executed commands?
Also not sure how we could surface this in lldb-dap?
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
