malor added a comment. In D108510#2961332 <https://reviews.llvm.org/D108510#2961332>, @jingham wrote:
> 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108510/new/ https://reviews.llvm.org/D108510 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
