[PATCH] D75343: [RFC][debuginfo-tests][dexter] Add a test generation tool

[Pierre van Houtryve via Phabricator via llvm-commits]

Pierre-vh added a comment.

In D75343#1905686 <https://reviews.llvm.org/D75343#1905686>, @TWeaver wrote:

> Hi Pierre,
>
> I'm working out the kinks on this proposal but I'd to get your input too,
>
> how do you feel about changing the way _get_step_info works? I'd like to make getting the step info as generic as possible so that we can compose different levels of information at the step getting point. I'd like to add abstract methods to debuggerbase for getting frame ir, loc ir, watch irs, function irs and all the other individual parts that make up a step, including your 'visible variables' .
>
> by being able to compose what information we want to gather at the 'getting step info' point we can choose how hard we want to the debugger to work. We could implement several different step info getters, ones that get a small portion of the information, gather all the info or some place in the middle.
>
> By adding abstract methods to debugger base we could implement the individual methods that get the IR in the different debuggers too.
>
> what do you think?
>
> I'm also working on stripping out the 'start' method within debugger base into a separate controller class so that we can separate debugger operating behaviour from the functions/features of the debugger itself. This may help with your 'step_collection.commands' issue as you could implement your own 'start' method in a different controller class
>
> It's still rather vague and early days but I welcome your feedback on these ideas.
>
> cheers
>  Tom W




- Breaking up `_get_step_info` into smaller pieces is definitely a good idea: In my opinion, the debugger classes should just act as "translators" between Dexter and the underlying debugger, nothing more, nothing less. Deciding what information to collect should be up to the caller.
  - Ideally, the API should allow the caller to choose what to collect //per frame//. This would be very useful for the generation tool, as it could ask the debugger to just return the set of visible variables in the top stack frame and then stop. A good alternative would to have a `maximum_depth` parameter (0 = no limit, 1 = collect info for just one frame, 2 = etc.)
- I believe that the `step`, `go` and `launch` methods should be renamed. Something like `step_in`, `continue` and `start_debugging_session` seem more appropriate to me. Their current name is a bit cryptic

That's all I can think of for now, I don't have many objections, your plan sounds good to me and would definitely be a step in the right direction.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75343/new/

https://reviews.llvm.org/D75343