[llvm-dev] [DebugInfo] RFC: Introduce LLVM DI Checker utility

[Djordje via llvm-dev]

Hi Adrian,

Thanks for the comments!

 > How would a tool like this distinguish between situations where debug 
locations are expected to be dropped or merged, such as the ones 
outlined in https://reviews.llvm.org/D81198? Is it generating false 
positives?

Since it is still a proposal, it does not cover these cases, but it 
shouldn't generate false positives in that case. My impression is that 
we can check if dropping/merging a location meets requirements outlined 
within D81198 (e.g. to check whether the instruction is in the same 
basic block when dropping occurs etc.) & mark it as a "known dropping".

 > You mention that "An alternative to this is the debugify utility, but 
the difference is that the LLVM DI Checker deals with real debug info, 
rather than with the synthetic ones". How is that an advantage? Are you 
seeing too many false positives with the debugify-generated debug locations?

I was wrong when saying "alternative". These two are more likely to be 
used in the combination. There are no false positives from debugify 
report (at least I haven't seen it; the same core logic was used for 
di-checker), but I think that since debugify deals with synthetic debug 
info it is potentially limited to certain set of metadata kinds that 
could be generated synthetically (but I might have been mistaken about 
that) & it is part of Transformation lib, but the di-checker performs 
analysis only (I am not sure what is the overhead if we run debugify on 
a large project on every single CU; my impression was that this analysis 
was chipper) &  the di-checker reports failures (instead of e.g for 
variables called "1", "2", etc.) for real entities such as "a", "b", 
etc. (and these are the entities being reported from users as "My var 
'a' is optimized out..." or "I cannot attach breakpoint to function 
'fn1()'"). I don't want to make a picture that we are choosing between 
these two, since I really think the debugify is great tool & these two 
can/should coexist. I use the di-checker to detect failures from clang's 
level & then I run debugify on the certain pass-test-directory. As I 
just mentioned, the di-checker option could be called from clang's 
level, since it has been linked into the IR library. In addition, the 
di-checker should be extended to support all kinds of debug info 
metadata, such as DILexicalScopes, DIGlobalVariables, dbg_labels, and so on.

Best,

Djordje

On 17.6.20. 19:03, Adrian Prantl wrote:
> That's a neat idea!
>
> How would a tool like this distinguish between situations where debug locations are expected to be dropped or merged, such as the ones outlined in https://reviews.llvm.org/D81198? Is it generating false positives?
>
> You mention that "An alternative to this is the debugify utility, but the difference is that the LLVM DI Checker deals with real debug info, rather than with the synthetic ones". How is that an advantage? Are you seeing too many false positives with the debugify-generated debug locations?
>
> -- adrian
>
>