<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks for all the feedback and ideas. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 (<a href="http://llvm.org/D79757">llvm.org/D79757</a>) 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 3:08 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">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...<div><br></div><div>Greg<br><div><div><br><blockquote type="cite"><div>On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi lldb-dev,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>TL;DR: </b>Has there been any efforts to introduce something like "Just My Code" debugging on LLDB? Debugging on Android would really benefit from this.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>Details:</b></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Native Android apps typically have a single .so file from the user, but load ~150 system libraries. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>Prototype and Experiments</b></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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" .<br></div><div class="gmail_default"><ul><li style="font-size:small">For warm LLDB cache:</li><ul style="font-size:small"><li>Without just-my-code: 23 seconds</li><li>With just-my-code: 14 seconds</li></ul><li>For cold LLDB cache:</li><ul><li>Without just-my-code: 120 seconds</li><li>With just-my-code: 16 seconds</li></ul></ul><div><br></div><div>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.<br></div><div><br></div><div>Thanks.</div><div>-Emre</div><div><br></div><div><br></div></div><div class="gmail_default" style="font-size:small"> </div><div class="gmail_default" style="font-size:small"></div></div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></div></blockquote></div><br></div></div></div></blockquote></div>