[lldb-dev] How to associate a bug and CL?

[Emre Kultursay via lldb-dev]

llvm-project dev noob here.

I opened a Bug  and have some
CLs  to fix them. How do I link the CL
with the bug so that the code reviewer sees what bug I'm fixing?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Emre Kultursay via lldb-dev]

Hi lldb-dev,

*TL;DR: *Has there been any efforts to introduce something like "Just My
Code" debugging on LLDB? Debugging on Android would really benefit from
this.

*Details:*

Native Android apps typically have a single .so file from the user, but
load ~150 system libraries.

When attaching LLDB remotely to an Android app, a significant amount of
time is spent on loading modules for those system libraries, even with a
warm LLDB cache that contains a copy of all these libraries.

With a cold LLDB cache, things are much worse, because LLDB copies all
those libraries from the device back to the host to populate its cache.
While one might think this happens only once for a user, things are a bit
worse for Android. There are just too many libraries to copy, making it
very slow, there are new Android releases every year, and users typically
use multiple devices (e.g., x86, x86_64 emulators, arm32, arm64 devices),
and multiple hosts (work, home, laptop/desktop); thereby suffering from
this issue more than necessary.

If we can eliminate the latency of loading these modules, we can deliver a
much faster debugging startup time. In essence, this can be considered as a
form of Just My Code debugging.

*Prototype and Experiments*

I built a simple prototype that only loads a single user module, and
totally avoids loading ~150 system modules. I ran it on my Windows host
against an Android emulator to measure the end to end latency of "Connect +
Attach + Resume + Hit 1st breakpoint immediately" .

   - For warm LLDB cache:
  - Without just-my-code: 23 seconds
  - With just-my-code: 14 seconds
   - For cold LLDB cache:
  - Without just-my-code: 120 seconds
  - With just-my-code: 16 seconds


I want to solicit some feedback and gather thoughts around this idea. It
would be great if there are any existing alternatives in LLDB to achieve my
goal, but otherwise, I can implement this on LLDB and I'd appreciate it if
anyone has any advice on how to implement such a feature.

Thanks.
-Emre
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Emre Kultursay via lldb-dev]

Thanks for all the feedback and ideas.

After Jim's comment about iOS performance, I decided to dig deeper to
figure out why it's much slower to attach on Android compared to iOS. I
identified an ipv6/ipv4 issue about adb and the simple fix (llvm.org/D79757)
brought warm cache attach time down from 23 seconds to ~9 seconds, and cold
cache attach time from 120 seconds down to 16-20 seconds!! These are much
better numbers, but based on the numbers from Jim, I should probably
continue hunting for more Android-specific issues.

One thing I want to try is "settings set
plugin.process.gdb-remote.use-libraries-svr4 true". I measure it takes
~600ms to read the list of shared libs without this flag, and it's done 3
times from startup until we hit the first-breakpoint (load all system
libraries at attach time; then load base.odex, then load user-lib.so). So,
I expect this to shave up to ~1.8 seconds. I don't have any numbers on this
yet (does anyone know how much improvement I can expect with this?)

About my "don't-load-system-modules" idea (that I mistakenly called
"my-code-only" which is apparently something different): Pavel's concerns
about not loading modules sounds serious, especially about impacting
stability, and I'd like to avoid causing trouble there. So, instead of
that, I will try Greg's idea of pre-caching libraries. I'll start with some
measurements. I'm working from top-of-tree (I'm trying to build LLDB with
libxml2 now).


On Wed, May 13, 2020 at 3:08 PM Greg Clayton  wrote:

> One reason to not only load your libraries is backtraces will be truncated
> for any stack frames that go through the system libraries. These tend to be
> in the stack traces a lot as we deal with Android all the time at
> Facebook...
>
> Greg
>
> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> *TL;DR: *Has there been any efforts to introduce something like "Just My
> Code" debugging on LLDB? Debugging on Android would really benefit from
> this.
>
> *Details:*
>
> Native Android apps typically have a single .so file from the user, but
> load ~150 system libraries.
>
> When attaching LLDB remotely to an Android app, a significant amount of
> time is spent on loading modules for those system libraries, even with a
> warm LLDB cache that contains a copy of all these libraries.
>
> With a cold LLDB cache, things are much worse, because LLDB copies all
> those libraries from the device back to the host to populate its cache.
> While one might think this happens only once for a user, things are a bit
> worse for Android. There are just too many libraries to copy, making it
> very slow, there are new Android releases every year, and users typically
> use multiple devices (e.g., x86, x86_64 emulators, arm32, arm64 devices),
> and multiple hosts (work, home, laptop/desktop); thereby suffering from
> this issue more than necessary.
>
> If we can eliminate the latency of loading these modules, we can deliver a
> much faster debugging startup time. In essence, this can be considered as a
> form of Just My Code debugging.
>
> *Prototype and Experiments*
>
> I built a simple prototype that only loads a single user module, and
> totally avoids loading ~150 system modules. I ran it on my Windows host
> against an Android emulator to measure the end to end latency of "Connect +
> Attach + Resume + Hit 1st breakpoint immediately" .
>
>- For warm LLDB cache:
>   - Without just-my-code: 23 seconds
>   - With just-my-code: 14 seconds
>- For cold LLDB cache:
>   - Without just-my-code: 120 seconds
>   - With just-my-code: 16 seconds
>
>
> I want to solicit some feedback and gather thoughts around this idea. It
> would be great if there are any existing alternatives in LLDB to achieve my
> goal, but otherwise, I can implement this on LLDB and I'd appreciate it if
> anyone has any advice on how to implement such a feature.
>
> Thanks.
> -Emre
>
>
>
> ___
> 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] Hiding local variables not defined yet

[Emre Kultursay via lldb-dev]

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

[Emre Kultursay via lldb-dev]

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

Re: [lldb-dev] Hiding local variables not defined yet

[Emre Kultursay via lldb-dev]

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