[lldb-dev] Is there a just-my-code like debugging mode for LLDB?
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] [Bug 45852] New: On i386, lldb prints "error: failed to launch or debug process" when trying to run any process
https://bugs.llvm.org/show_bug.cgi?id=45852 Bug ID: 45852 Summary: On i386, lldb prints "error: failed to launch or debug process" when trying to run any process Product: lldb Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: anthony.louis.e...@gmail.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Confirmed on ArchLinux32 [1] and Debian bullseye, lldb (versions 10 and 9 both exhibit the following) fails to launch any process. It is easy to reproduce, just try $ lldb $(which date) (lldb) target create "/usr/bin/date" Current executable set to '/usr/bin/date' (i386). (lldb) run error: failed to launch or debug process [1] ArchLinux32 bug report: https://bugs.archlinux32.org/index.php?do=details&task_id=108 -- 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] Is there a just-my-code like debugging mode for LLDB?
On iOS, every time a device that is provisioned for debugging is plugged in, the device management stack checks to see if it knows the OS on the device and if not copies the libraries from the system to the host and puts them in a location that lldb can find. That shouldn’t be a big job if the throughput to the device is decent. Originally this took a couple minutes to process on iOS. That was annoying but except for folks working at Apple who had to update their devices every day it was never a burning issue because you always knew when it was going to happen (Xcode gave you a nice progress bar, etc.) Note, internal folks did complain enough that we eventually got around to looking at why it was so slow and found that almost all of that time was taking the iOS “shared cache” - which is how the libraries exist on the device - and expanding it into shared libraries. This was being done single-threaded, and just doing this concurrently got the time down to 10 or 20 seconds. Given you only do this once per os update on your device, this doesn’t seem to bother people anymore. Once the shared libraries from the device are available on the lldb host, startup times for running an app to first breakpoint are nowhere near 23 seconds. Since you were quoting times for a simulator, I tried debugging an iOS game app that loads 330 shared libraries at startup. Launching an app from a fresh lldb (from hitting Run in Xcode to hitting a breakpoint in applicationDidFinishLaunching, fetching all the stacks of all the threads and displaying the locals for the current frame as well as calling a bunch of functions in the expression parser to get Queue information for all the threads) took 4-5 seconds. And the warm launch was just a second or two. So I’m surprised that it takes this long to load on Android. Before we go complicating how lldb handles symbols, it might be worth first figuring out what lldb is doing differently on Android that is causing it to be an order of magnitude slower? Note, if you are reading the binaries out of memory from the device, and don’t have local symbols, things go much more slowly. gdb-remote is NOT a high bandwidth protocol, and fetching all the symbols through a series of memory reads is pretty slow. lldb does have a setting to control what you do with binaries that don’t exist on the host (target.memory-module-load-level) that controls this behavior. But it just deals with what we do and don’t read and makes no attempt to ameliorate the fallout from having a reduced view of the symbols in the program. We did add a “debug just my code” mode to gdb back in the day, when we were supporting gdb here at Apple. Basically just a load-level for symbols for libraries whose path matches some pattern. gdb was quite slow to process libraries at that point, and this did speed loading up substantially. It wasn’t that hard to implement, but it had a bunch of fallout. Mainly because even though people think they would like to only debug their own code, they actually venture into system code pretty regularly... For instance, if you don’t have symbols for libraries, the backtracing becomes unreliable. We had to add code to force load libraries when they show up in backtraces to get reliable unwinding, which generally meant you had to restart the unwind when you found an unloaded library. People also commonly want to set breakpoints on system functions which if you haven’t read symbols you can’t do.I don’t know about Android but on iOS and macOS there are common symbolic breakpoints that people set, to catch error conditions and the like. To work around this we added code so that if you specified a shared library when you set a breakpoint we would read in that shared library’s symbols, but it was hard to get people to use this. People also very commonly call system libraries in expressions for a whole variety of reasons. There’s no way to express to the expression parser that it should try to load symbols from libraries (and which ones) when it encounters an identifier it can’t find. You’d probably need to do that. There were other tweaks we had to add to gdb to make this work nicely, but that was a long time ago and I can’t remember them right now… The other problem with this approach is that it often just takes a bunch of work that happens predictably when the user starts the debugger, and instead makes it happen at some time later, and if it isn’t clear to the user what is triggering this slowdown, that is a much worse experience. Anyway, I don’t see why startup should be taking so long for Android. It would be better to make sure we can't improve whatever is causing these delays before we start complicating lldb with this sort of progressive loading of library symbols. Jim > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev > wrote: > > Hi lldb-dev, > > TL;DR: Has there been any efforts to introduce s
[lldb-dev] [Bug 45853] New: lldb:buggy expression unit test
https://bugs.llvm.org/show_bug.cgi?id=45853 Bug ID: 45853 Summary: lldb:buggy expression unit test Product: lldb Version: 10.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ggr...@gmail.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org https://github.com/llvm/llvm-project/blob/master/lldb/unittests/Expression/DWARFExpressionTest.cpp#L207-L212 Contains extra (bogus) instructions `0xee, 0xff`, probably due to a c&p error. Here is a fix for cherry-picking: https://github.com/ggreif/llvm-project/commit/ef6f96bcc8230ad1014d1863cd5eae0f2a32e827 Please indicate if I should submit a PR with a dedicated branch. -- 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
[lldb-dev] [Bug 45856] New: UTF8 data printed differently before and after program start
https://bugs.llvm.org/show_bug.cgi?id=45856
Bug ID: 45856
Summary: UTF8 data printed differently before and after program
start
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: pro.mathias.l...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
test.cpp:
```
extern const char8_t data[12] = u8"Hello World";
int main () { return 0; }
```
Compiled with `clang++ -g -std=c++2a test.cpp`.
Running it under LLDB:
```
(lldb) target create "./a.out"
Current executable set to
'/Users/geod24/projects/dlang/llvm-project/lldb/a.out' (x86_64).
(lldb) p data
(const char8_t [12]) $0 = {
[0] = 0x48 u8'H'
[1] = 0x65 u8'e'
[2] = 0x6c u8'l'
[3] = 0x6c u8'l'
[4] = 0x6f u8'o'
[5] = 0x20 u8' '
[6] = 0x57 u8'W'
[7] = 0x6f u8'o'
[8] = 0x72 u8'r'
[9] = 0x6c u8'l'
[10] = 0x64 u8'd'
[11] = 0x00 u8'\0'
}
(lldb) b main
Breakpoint 1: where = a.out`main + 13 at test.cpp:2:15, address =
0x00010f9d
(lldb) run
Process 54857 launched: '/Users/geod24/projects/dlang/llvm-project/lldb/a.out'
(x86_64)
Process 54857 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f9d a.out`main at test.cpp:2:15
1extern const char8_t data[12] = u8"Hello World";
-> 2int main () { return 0; }
Target 0: (a.out) stopped.
(lldb) p data
(const char8_t [12]) $1 = u8"Hello World"
```
I would expect the output to be consistent before and after the program
started.
Tested under MacOSX 10.15, with the latest lldb (f058d397ff8). The issue isn't
C++ specific, as it was found while working on https://reviews.llvm.org/D79559
.
--
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
