Re: Inspecting function arguments in GHCi

Hi Andrew, I updated the README for ghc-debug last week but forget to send this mail! https://gitlab.haskell.org/ghc/ghc-debug Cheers, Matt On Wed, Jan 27, 2021 at 10:15 PM Andrew Kvapil wrote:

Hello Ben,

Thanks for your suggestions. The decision to adapt GHCi came out of a discussion with my supervisor and his colleagues. At this point the entire set of desired capabilities of the work is still unknown, however we do consider the GHCi-compatible programs to represent a large enough set for future analysis, and the ease of mapping breakpoints back to source code is a significant benefit.

I do plan on using the ghc-heap-view (I assume that's what you meant by ghc-heap, or is there another library I don't know about?) logic in the project, although I'm currently more focused on implementing the proper hook mechanism. I expect that events of deeply nested thunks being forced will be quite important. The possibility of tracking control flow via breakpoints/tracepoints also seems appealing. I'm not aware of any existing solutions which would allow dynamic tracing, although it's very well possible I didn't look hard enough.

Regarding ghc-debug, I'm not sure what kinds of trade-offs it offers compared to the approach I'm currently taking. It looks like it's a fairly newborn project, do you think it's mature enough for the proposed use cases? I couldn't find docs online, although I did come across [0] which Discourse[1] says is related. I've yet to watch the introduction video. Support for unboxed tuples and other features not supported by GHCi would of course be nice, although performance is not a concern. Keeping the relationship between source code spans and heap objects in the infotables is an intriguing idea.

...

Note that Luite's recent work on refactoring the bytecode generator to

...

produce code from STG is quite relevant here. In particular, you will

...

likely want to look at !4589 [1], which does the work of refactoring

...

Tickish to follow the Trees That Grow pattern. You would likely want to

...

do the same to capture your free variable information.

Excellent, I was not aware of this. Thank you!

Regards, Andrew

[0]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [1]: https://discourse.haskell.org/t/an-introduction-to-ghc-debug-precise-memory-...

On 26/01/2021 16:28, Ben Gamari wrote:

...

Andrew Kvapil writes:

...

Hello,

I'm interested in inspecting the strictness of functions at runtime and the depth of thunks "in the wild."

Hi Andrew,

Interesting. When I first read your introduction my first thought was to rather walk the "normal" heap using ghc-heap or, perhaps, the relatively new ghc-debug library [1] rather than introduce this feature in GHCi. It's hard to know whether non-GHCi-based approach is viable without knowing more about what you are doing, but it potentially brings the benefit of generality: your analysis is not limited to programs with can be run under GHCi.

Of course, it also brings some challenges: You would need to find a way to associate info table symbols with whatever information you need of from the Core program and in the presence of simplification tying your results back to the source program may not be possible at all.

Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc-debug

...

For this reason I'm modifying GHC 8.10.2, essentially to add additional information to breakpoints. I'd like to reuse the logic behind GHCi's :print command (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I need Id's. Those however don't exist for destructuring patterns, such as those in the following equations:

last [x] = x last (_:xs) = last xs

So I'm wondering where would be a good place in the pipeline to transform patterns like these into at-patterns, to give them Id's. However, the breakpoint logic only looks at the free variables of the right-hand sides and not transitively, which means that e.g. in the following example neither ':print arg1' nor ':print as' works when the interpreter hits a breakpoint in the top level expression on the RHS:

qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right where (left, right) = (filter (<=a) as, filter (>a) as)

Thus I'd also like to know how to extend the free var logic for Tickish that eventually leads to CgBreakInfo and :print's ability to inspect these bindings at runtime. My goal would be to determine to what extent was a thunk evaluated during function application.

Note that Luite's recent work on refactoring the bytecode generator to produce code from STG is quite relevant here. In particular, you will likely want to look at !4589 [1], which does the work of refactoring Tickish to follow the Trees That Grow pattern. You would likely want to do the same to capture your free variable information.

Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4589

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs