This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Allow to register frame recognizers applied beyond the first instruction
ClosedPublic

Authored by malor on Aug 21 2021, 9:04 AM.

Details

Summary

It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.

The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.

Diff Detail

Event Timeline

malor created this revision.Aug 21 2021, 9:04 AM
malor requested review of this revision.Aug 21 2021, 9:04 AM

One of the key reasons to use "frame recognizers" is to provide argument values to functions that don't have debug information. That generally only works when stopped at the first instruction, since otherwise you have to follow the value as it moves through the code, which in the absence of debug information isn't entirely trivial.

A naive user might think reporting expr (SomeType *) $arg1 is going to always work, but in fact it only works reliably on the first instruction.

I don't think that possible incorrect usage means we should only allow frame recognizers on the first instruction. But I do think we should say something more in the help for this flag, like "remember that $arg<N> is only reliable on the first instruction" to warn folks in advance of this pitfall.

One of the key reasons to use "frame recognizers" is to provide argument values to functions that don't have debug information. That generally only works when stopped at the first instruction, since otherwise you have to follow the value as it moves through the code, which in the absence of debug information isn't entirely trivial.

A naive user might think reporting expr (SomeType *) $arg1 is going to always work, but in fact it only works reliably on the first instruction.

I don't think that possible incorrect usage means we should only allow frame recognizers on the first instruction. But I do think we should say something more in the help for this flag, like "remember that $arg<N> is only reliable on the first instruction" to warn folks in advance of this pitfall.

Thank you, Jim! That makes sense. I figured it was something along those lines.

Funnily enough, the way I ran into this issue is that I tried to add a frame recognizer for a binary that had debug information. In that case, doing something like breakpoint set -n foo actually sets the breakpoint *right after* the prologue of a function, so execution won't stop at the first instruction but at something like foo+4, and thus the frame recognizer won't be applied.

I think we should give users a choice and keep the current behavior of only applying recognizers to the first instruction as the default. I'll upload a new revision with the updated documentation.

malor updated this revision to Diff 368565.Aug 25 2021, 12:26 AM

Updated the description of the flag to incorporate Jim's feedback.

This revision is now accepted and ready to land.Aug 25 2021, 11:16 AM
malor added a comment.Aug 29 2021, 6:50 AM

Thank you, Jim! Would you be able to submit this change?

The clang-tidy premerge check has failed, but I don't think it's actionable: it's complaining about an #include in the file that I'm not modifying -- I saw it failing in the same way (although, on different files) in other review patches as well.

mib added a comment.Aug 29 2021, 8:37 AM

Hi Roman, thanks for your patch. It also looks good to me, so I'll land it for you.

mib accepted this revision.Aug 29 2021, 8:37 AM
This revision was landed with ongoing or failed builds.Aug 29 2021, 8:38 AM
This revision was automatically updated to reflect the committed changes.

Hi Roman, thanks for your patch. It also looks good to me, so I'll land it for you.

Thank you, Med!