> On Aug 24, 2021, at 11:57 AM, Roman Podoliaka via Phabricator 
> <revi...@reviews.llvm.org> wrote:
> 
> 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.

If you are relying on "first instruction" behavior for breakpoints you can pass 
"--skip-prologue 0" when you set the breakpoint.  For source debugging, you 
generally want to stop after the prologue because debug info doesn't generally 
describe variable locations in the prologue, so the locals variable values will 
likely be wrong.


> 
> 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.
> 

SGTM

Jim

> 
> 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

Reply via email to