Re: [lldb-dev] Hiding local variables not defined yet
> > LLDB does only show variables that are in lexical scope in ... Ah, yes, I got confused because I thought this filter was implemented inside LLDB, yet the `frame variable` command was returning me all local variables; I now notice that it's a filter that's implemented inside the IDE (I'm looking at Android Studio). Thanks for the explanation and also the details about the compiler provided info. On Fri, Apr 9, 2021 at 10:15 PM Greg Clayton wrote: > > > On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > When debugging C/C++ (statically scoped languages), does LLDB recognize > (or does it have a setting for it) that a local variable is not defined yet > at the current program address (i.e., DW_AT_decl_line is less than the > source line for the address), and thus, not include it in the list of > locals (i.e., frame variable)? > > Does it make sense to have such a setting? The goal is to reduce the > clutter in locals list. > > > LLDB does not. We show exactly what the compiler emits. DWARF, the debug > information, is powerful enough to say from [0x1000-0x1010) the variable is > here, and from [0x1020-0x1100) the variable is there, these are called > location expressions. But the compiler, for non optimized code, always just > emits the variable's location on the stack and doesn't correctly limit it > to when the variable has been initialized. > > So this could easily be fixed in the compiler. LLDB really needs to listen > to what the compiler says because once you enable optimizations, the > compiler can end up moving all sorts of code around and the variable > _could_ become initialized before the DW_AT_decl_line. > > So we don't want to pretend we know better than the compiler when > displaying debug information. But even if the compiler does emit better > debug information that does give correct location expressions, we would > still show the variable because it is in scope. LLDB does only show > variables that are in lexical scope currently in Xcode, lldb-vscode, lldb, > and Android Studio AFAIK. What debugger are you using? > > Greg > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 49941] New: register commands require a frame unconditionally
https://bugs.llvm.org/show_bug.cgi?id=49941 Bug ID: 49941 Summary: register commands require a frame unconditionally Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: l...@jade.fyi CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org I've been trying out lldb as a replacement for gdb for working on my operating system, which I develop on qemu with a gdbstub. Part of this involves debugging code that is run before the initialization of the stack, in early startup code and exception handlers. Here is an example thing that can go wrong: ``` (lldb) register write t0 123 error: invalid frame ``` The `register read` command is also affected by this issue. It appears that the cause of it is that a bunch of the commands in `CommandObjectRegister.cpp` are defined as `eCommandRequiresFrame` when they should handle there not being a frame present with slightly degraded functionality. It's not that they don't require a frame at all though: `ExecutionContext::GetRegisterContext` needs a frame to work, but it should be skipped if one is unavailable, which it is not currently. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Hiding local variables not defined yet
Looking at Android Studio implementation a little deeper, it actually does the filtering the way I described in my first email, by comparing line numbers. It does not use the location expressions. Do you have a pointer to another implementation (e.g., lldb-vscode) that filters based on location expressions, for comparison? On Mon, Apr 12, 2021 at 12:31 PM Emre Kultursay wrote: > LLDB does only show variables that are in lexical scope in ... > > Ah, yes, I got confused because I thought this filter was implemented > inside LLDB, yet the `frame variable` command was returning me all local > variables; I now notice that it's a filter that's implemented inside the > IDE (I'm looking at Android Studio). > > Thanks for the explanation and also the details about the compiler > provided info. > > > On Fri, Apr 9, 2021 at 10:15 PM Greg Clayton wrote: > >> >> >> On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> When debugging C/C++ (statically scoped languages), does LLDB recognize >> (or does it have a setting for it) that a local variable is not defined yet >> at the current program address (i.e., DW_AT_decl_line is less than the >> source line for the address), and thus, not include it in the list of >> locals (i.e., frame variable)? >> >> Does it make sense to have such a setting? The goal is to reduce the >> clutter in locals list. >> >> >> LLDB does not. We show exactly what the compiler emits. DWARF, the debug >> information, is powerful enough to say from [0x1000-0x1010) the variable is >> here, and from [0x1020-0x1100) the variable is there, these are called >> location expressions. But the compiler, for non optimized code, always just >> emits the variable's location on the stack and doesn't correctly limit it >> to when the variable has been initialized. >> >> So this could easily be fixed in the compiler. LLDB really needs to >> listen to what the compiler says because once you enable optimizations, the >> compiler can end up moving all sorts of code around and the variable >> _could_ become initialized before the DW_AT_decl_line. >> >> So we don't want to pretend we know better than the compiler when >> displaying debug information. But even if the compiler does emit better >> debug information that does give correct location expressions, we would >> still show the variable because it is in scope. LLDB does only show >> variables that are in lexical scope currently in Xcode, lldb-vscode, lldb, >> and Android Studio AFAIK. What debugger are you using? >> >> Greg >> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> >> ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 49946] New: python SBTarget.EvaluateExpression cannot call selectors prefixed with underscore
https://bugs.llvm.org/show_bug.cgi?id=49946
Bug ID: 49946
Summary: python SBTarget.EvaluateExpression cannot call
selectors prefixed with underscore
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: matan1...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
to whom it may concern,
I am using the official LLDB python api in the project hilda
(https://github.com/doronz88/hilda).
When trying to evaluate an expression in MobileSafari process I noticed that
evaluating methods prefixed with underscore has unexpected behavior.
My code was:
options = lldb.SBExpressionOptions()
options.SetIgnoreBreakpoints(True)
options.SetTryAllThreads(True)
e = target.EvaluateExpression('[NSUserDefaults _sf_safariDefaults]')
e.error.Success() # This one turns as False
When printing str(e.error) I see:
error: :1:17: no known method '+_sf_safariDefaults'; cast
the message send to the method's return type
It seems that for some reason, LLDB added '+' before the _sf_safariDefaults.
Also, I tried running from the LLDB command line with 'expr -o' and it worked
well, so I think the problem might be somewhere in the API.
I would really like your help solving this problem.
Thanks for dedicating time!
Matan.
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
