[PATCH] D116305: [CSInfo][clang][ISEL][RISCV] Support for recovering optimized debug function parameters

Djordje Todorovic via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 18 23:54:26 PST 2022


djtodoro added a comment.

Hi @jrtc27:)

In D116305#3251884 <https://reviews.llvm.org/D116305#3251884>, @jrtc27 wrote:

> This whole scheme seems like a pretty bad idea, is that really how the debug infrastructure works, scavenging generated code to figure out what arguments were passed rather than just remembering from the input? This all seems pretty fragile. I mean, if that's what we need to do to make it work then I guess we have to, but I really do not like this code...

I am not sure If I understood this, can you please elaborate what exactly is bad idea?

This is all part of the Debug Entry Values feature that improves debugging user experience of optimized code. The feature was divided into two parts: callee and caller. The callee part implements production of `DW_OP_entry_value` DWARF expressions, which indicates that debugger should jump into parent's frame and look for a value of the parameter that was available at the call-site. The info at call site we call `caller side`. The caller side generates info about parameter's value. We need an info about what register was used for passing arguments since we need to express the value that was passed in, in terms of DWARF (expression), very late in the pipeline (when doing the `AsmPrinter`/`DwarfDebug`). During the `ISel` phase, the compiler remembers the info into the `MF` attribute, so it can be used later.

An alternative was to introduce some additional metadata, that would be generated at fronted, but keeping such info (valid) throughout pipeline is very expensive.


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

https://reviews.llvm.org/D116305



More information about the llvm-commits mailing list