[lldb-dev] [Bug 29138] lldb uses internal lib/Support/regex_impl.h LLVM header
https://bugs.llvm.org/show_bug.cgi?id=29138 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jdevliegh...@apple.com --- Comment #5 from Jonas Devlieghere --- The original issue was fixed by the removal of lldb-mi. In the meantime I've also migrated LLDB's RegularExpression to leverage llvm::Regex (r369153). -- 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] [RFC] Fast Conditional Breakpoints (FCB)
Hi Pavel, Thanks for all your feedbacks. I’ve been following the discussion closely and find your approach quite interesting. As Jim explained, I’m also trying to have a conditional breakpoint, that is able to stop a specific thread (name or id) when the condition expression evaluates to true. I feel like stacking up options with your approach would imply doing more context switches. But it’s definitely a better fallback mechanism than the current one. I’ll try to make a prototype to see the performance difference for both approaches. > On Aug 15, 2019, at 10:10 AM, Pavel Labath wrote: > > Hello Ismail, and wellcome to LLDB. You have a very interesting (and not > entirely trivial) project, and I wish you the best of luck in your work. I > think this will be a very useful addition to lldb. > > It sounds like you have researched the problem very well, and the overall > direction looks good to me. However, I do have some ideas suggestions about > possible tweaks/improvements that I would like to hear your thoughts on. > Please find my comments inline. > > On 14/08/2019 22:52, Ismail Bennani via lldb-dev wrote: >> Hi everyone, >> I’m Ismail, a compiler engineer intern at Apple. As a part of my internship, >> I'm adding Fast Conditional Breakpoints to LLDB, using code patching. >> Currently, the expressions that power conditional breakpoints are lowered >> to LLVM IR and LLDB knows how to interpret a subset of it. If that fails, >> the debugger JIT-compiles the expression (compiled once, and re-run on each >> breakpoint hit). In both cases LLDB must collect all program state used in >> the condition and pass it to the expression. >> The goal of my internship project is to make conditional breakpoints faster >> by: >> 1. Compiling the expression ahead-of-time, when setting the breakpoint and >>inject into the inferior memory only once. >> 2. Re-route the inferior execution flow to run the expression and check >> whether >>it needs to stop, in-process. >> This saves the cost of having to do the context switch between debugger and >> the inferior program (about 10 times) to compile and evaluate the condition. >> This feature is described on the [LLDB Project >> page](https://lldb.llvm.org/status/projects.html#use-the-jit-to-speed-up-conditional-breakpoint-evaluation). >> The goal would be to have it working for most languages and architectures >> supported by LLDB, however my original implementation will be for C-based >> languages targeting x86_64. It will be extended to AArch64 afterwards. >> Note the way my prototype is implemented makes it fully extensible for other >> languages and architectures. >> ## High Level Design >> Every time a breakpoint that holds a condition is hit, multiple context >> switches are needed in order to compile and evaluate the condition. >> First, the breakpoint is hit and the control is given to the debugger. >> That's where LLDB wraps the condition expression into a UserExpression that >> will get compiled and injected into the program memory. Another round-trip >> between the inferior and the LLDB is needed to run the compiled expression >> and extract the expression results that will tell LLDB to stop or not. >> To get rid of those context switches, we will evaluate the condition inside >> the program, and only stop when the condition is true. LLDB will achieve this >> by inserting a jump from the breakpoint address to a code section that will >> be allocated into the program memory. It will save the thread state, run the >> condition expression, restore the thread state and then execute the copied >> instruction(s) before jumping back to the regular program flow. >> Then we only trap and return control to LLDB when the condition is true. >> ## Implementation Details >> To be able to evaluate a breakpoint condition without interacting with the >> debugger, LLDB changes the inferior program execution flow by overwriting >> the instruction at which the breakpoint was set with a branching instruction. >> The original instruction(s) are copied to a memory stub allocated in the >> inferior program memory called the __Fast Conditional Breakpoint Trampoline__ >> or __FCBT__. The FCBT will allow us the re-route the program execution flow >> to >> check the condition in-process while preserving the original program >> behavior. >> This part is critical to setup Fast Conditional Breakpoints. >> ``` >> Inferior Binary Trampoline >> |.| +-+ >> |.| | | >> |.| +->+ Save RegisterContext | >> |.| | | | >> +-+ | +-+ >> | | | | | >> |
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
On 8/16/19 10:27 AM, Adrian Prantl wrote: > >> On Aug 15, 2019, at 2:03 PM, Ismail Bennani via lldb-dev >> wrote: >> >> I built Clang (and LLVM) in Release Mode with Debug Info (-O2), >> and got these results: >> >> | Dwarf Occurences |Occurences | >> |--|-| >> | DW\_OP\_deref|1,570| >> | DW\_OP\_const|3,791| >> | DW\_OP\_addr |9,528| >> | DW\_OP\_lit |62,826 | >> | DW\_OP\_fbreg|205,382 | >> | DW\_OP\_piece|242,888 | >> | DW\_OP\_stack\_value |992,261 | >> | DW\_OP\_breg |1,006,070| >> | DW\_OP\_reg |5,175,831| >> | **Total**| **7,700,147** | >> >> >> I could technically implement the logic to support DW_OP_reg, DW_OP_breg >> and DW_OP_stack_value fairly easily (which still represents 90% of all ops). >> >> However, DW_OP_piece is a more complex operation since it combines >> several other operations, and would require more work. >> >> This would also imply that there will 2 DWARF Expression Interpreter in >> LLDB, hence twice as much code to maintain … I’ll try to see if I can >> use the existing interpreter for this feature. > I strongly agree that unless the code can be shared, the JIT-ed DWARF > expression interpreter should be kept as simple as possible and aim to > support the lion's share of DWARF expressions encountered in a typical > program, but making it support 100% is a lot of effort and maintenance burden > with very diminishing returns. +1 (and, thanks for the data! I think it would be useful to support the things that we can easily support, but the more complicated things should be weighed carefully against the maintenance costs) -Hal > > -- adrian > >> Ismail >> >>> On Aug 14, 2019, at 3:42 PM, Finkel, Hal J. wrote: >>> >>> >>> On 8/14/19 3:52 PM, Ismail Bennani via lldb-dev wrote: Hi everyone, I’m Ismail, a compiler engineer intern at Apple. As a part of my internship, I'm adding Fast Conditional Breakpoints to LLDB, using code patching. ... Since all the registers are already mapped to a structure, I should be able to support more __DWARF Operations__ in the future. After collecting some metrics on the __Clang__ binary, built at __-O0__, the debug info shows that __99%__ of the most used DWARF Operations are : |DWARF Operation| Occurrences | |---|---| |DW\_OP_fbreg | 2 114 612 | |DW\_OP_reg | 820 548 | |DW\_OP_constu | 267 450 | |DW\_OP_addr|17 370 | | __Top 4__ | __3 219 980 Occurrences__ | |---|---| | __Total__ | __3 236 859 Occurrences__ | Those 4 operations are the one that I'll support for now. To support more complex expressions, we would need to JIT-compile a DWARF expression interpreter. >>> >>> First, this all sounds really useful. >>> >>> Out of curiosity, how do these statistics change if you compile Clang >>> with -O1? Many of my users need to debug slightly-optimized code. >>> >>> -Hal >>> >>> >>> -- >>> Hal Finkel >>> Lead, Compiler Technology and Programming Languages >>> Leadership Computing Facility >>> Argonne National Laboratory >>> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
> On Aug 15, 2019, at 2:03 PM, Ismail Bennani via lldb-dev > wrote: > > I built Clang (and LLVM) in Release Mode with Debug Info (-O2), > and got these results: > > | Dwarf Occurences |Occurences | > |--|-| > | DW\_OP\_deref|1,570| > | DW\_OP\_const|3,791| > | DW\_OP\_addr |9,528| > | DW\_OP\_lit |62,826 | > | DW\_OP\_fbreg|205,382 | > | DW\_OP\_piece|242,888 | > | DW\_OP\_stack\_value |992,261 | > | DW\_OP\_breg |1,006,070| > | DW\_OP\_reg |5,175,831| > | **Total**| **7,700,147** | > > > I could technically implement the logic to support DW_OP_reg, DW_OP_breg > and DW_OP_stack_value fairly easily (which still represents 90% of all ops). > > However, DW_OP_piece is a more complex operation since it combines > several other operations, and would require more work. > > This would also imply that there will 2 DWARF Expression Interpreter in > LLDB, hence twice as much code to maintain … I’ll try to see if I can > use the existing interpreter for this feature. I strongly agree that unless the code can be shared, the JIT-ed DWARF expression interpreter should be kept as simple as possible and aim to support the lion's share of DWARF expressions encountered in a typical program, but making it support 100% is a lot of effort and maintenance burden with very diminishing returns. -- adrian > > Ismail > >> On Aug 14, 2019, at 3:42 PM, Finkel, Hal J. wrote: >> >> >> On 8/14/19 3:52 PM, Ismail Bennani via lldb-dev wrote: >>> Hi everyone, >>> >>> I’m Ismail, a compiler engineer intern at Apple. As a part of my internship, >>> I'm adding Fast Conditional Breakpoints to LLDB, using code patching. >>> >>> ... >>> >>> Since all the registers are already mapped to a structure, I should >>> be able to support more __DWARF Operations__ in the future. >>> >>> After collecting some metrics on the __Clang__ binary, built at __-O0__, >>> the debug info shows that __99%__ of the most used DWARF Operations are : >>> >>> |DWARF Operation| Occurrences | >>> |---|---| >>> |DW\_OP_fbreg | 2 114 612 | >>> |DW\_OP_reg | 820 548 | >>> |DW\_OP_constu | 267 450 | >>> |DW\_OP_addr|17 370 | >>> >>> | __Top 4__ | __3 219 980 Occurrences__ | >>> |---|---| >>> | __Total__ | __3 236 859 Occurrences__ | >>> >>> Those 4 operations are the one that I'll support for now. >>> To support more complex expressions, we would need to JIT-compile >>> a DWARF expression interpreter. >> >> >> First, this all sounds really useful. >> >> Out of curiosity, how do these statistics change if you compile Clang >> with -O1? Many of my users need to debug slightly-optimized code. >> >> -Hal >> >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> > > ___ > 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] test suite issue with Python2.7/3.5
> The 7.0 branch is not compatible with Python 3 .. The first release that is, > would be 9.0 Should some/all of the recent Python/CMake changes be ported to the 9.0 release branch? ‘git log --grep ython’ turns up r367956, r367153, r367127, r367125, r367115, r366447, and r366383, all of which happened after the fork, I’m wondering if any of them (or others) are important as part of supporting Python 3. I’ll paste the commit messages below for convenience. Thanks, -Joseph Author: Jonas Devlieghere Date: Mon Aug 5 23:54:13 2019 + [CMake] Remove check for the readline target. This was introduced when we were building a custom readline Python module on Linux [1]. Now that the readline target doesn't exist anymore, it's safe to remove this dependency. This fixes https://llvm.org/PR25136 [1] https://reviews.llvm.org/D13268 llvm-svn: 367956 Author: Jonas Devlieghere Date: Fri Jul 26 20:58:10 2019 + [CMake] Print the correct variables This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the variables ourselves. llvm-svn: 367153 Author: Jonas Devlieghere Date: Fri Jul 26 16:32:49 2019 + [CMake] Fix find_python_libs_windows Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my last change. Add it back again. This should fix the Windows bot! llvm-svn: 367127 Author: Jonas Devlieghere Date: Fri Jul 26 16:15:19 2019 + [CMake] Print Python version on Windows Trying to figure out what's causing the Windows bot to fail. llvm-svn: 367125 Author: Jonas Devlieghere Date: Fri Jul 26 14:26:33 2019 + [CMake] Loosen Python version check and ignore patch version Some versions of macOS report a different patch version for the system provided interpreter and libraries. Differential revision: https://reviews.llvm.org/D65230 llvm-svn: 367115 Author: Jonas Devlieghere Date: Thu Jul 18 15:17:42 2019 + [CMake] Don't set Python_ADDITIONAL_VERSIONS Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's Python support to 2.7. Now that both LLVM and LLDB both support Python 3, there's no longer a need to put an arbitrary limit on this. However, instead of removing the variable, r365692 expanded the list, which has the (presumably unintentional) side-effect of expression preference for Python 3. Instead, as Michal proposed in the original code review, we should just not set the list at all, and let CMake pick whatever Python interpreter you have in your path. This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm, clang and lld. I've also updated the docs with the default behavior and how to force a different Python version to be used. Differential revision: https://reviews.llvm.org/D64894 llvm-svn: 366447 Author: Adrian McCarthy Date: Wed Jul 17 22:36:26 2019 + [NFC] Clarify a Cmake status message regarding Python on LLDBConfig llvm-svn: 366383 From: lldb-dev On Behalf Of Jonas Devlieghere via lldb-dev Sent: Tuesday, July 23, 2019 10:52 AM To: Romaric Jodin Cc: LLDB Subject: Re: [lldb-dev] test suite issue with Python2.7/3.5 The 7.0 branch is not compatible with Python 3, at least not if you're not on Windows. The first release that is, would be 9.0, which is currently being qualified. This includes a bunch of compatibility fixes, and a newer version of the vendored pexpect (4.6). As you've noticed, using different versions of Python will not work either. Your only option is to use Python 2.7, both for building LLDB and for running the test suite. Making sure the 2.7 interpreter is first in your PATH should be sufficient. Alternatively, you can explicitly pass -DPYTHON_EXECUTABLE=/path/to/python27. Cheers, Jonas On Tue, Jul 23, 2019 at 7:38 AM Romaric Jodin via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: Hi everyone, I'm trying to run the test suite on lldb and I'm having some issues with Python. I'm on branch 7.0. When I build lldb, I've got a folder "python3.5/site-packages" generated. So I believe that the build system found python3 in my environment. But when I run the testsuite (using "ninja check-lldb"), I've got this issue: Traceback (most recent call last): File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 113, in wrapper func(*args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 341, in wrapper return func(self, *args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py", line 39, in test_command_regex child.expect_exact(prompt) File
[lldb-dev] [Bug 43017] New: Can't the SBDebugger API be used directly on android?
https://bugs.llvm.org/show_bug.cgi?id=43017 Bug ID: 43017 Summary: Can't the SBDebugger API be used directly on android? Product: lldb Version: 8.0 Hardware: Other OS: other Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mryus...@live.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org I want to use the LLDB SBDebugger API to create a debugger, create targets, set breakpoints, load processes, and use the SBDebugger API to get stack information. On linux: SBDebugger::Initialize(); SBDebugger debugger = SBDebugger::Create(); SBTarget target = degugger.CreateTarget(); Then create breakpoint and set some parameters, target.Launch(); In this way, the stack information can be successfully obtained. However, on android, there is apk,xx.so in the android installation directory. We don't know what the filename of CreateTarget is set when creating the target. Obviously, both apk and xx.so are wrong.But we still try the apk, because on android is also made of the elf format reads the target information, the format of the apk is not the elf, and then try the xx. So, read the target information is correct, but in GDBRemoteCommunication: : StartDebugserverProcess program in the Lord, then using the androidstudio LLDB - server, process Launch success, but there is no stack information. Can I use the SBDebugger API to directly debug on android? Please help me, thank you! -- 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] [Release-testers] [9.0.0 Release] Release Candidate 2 is here
Le 14/08/2019 à 10:14, Hans Wennborg via Release-testers a écrit : Hello everyone, 9.0.0-rc2 was tagged yesterday from the release_90 branch at r368683. In the Git monorepo it's available as the llvmorg-9.0.0-rc2 tag. [...] Release testers: please start your engines, run the script, share your results, and upload binaries. Bonjour, One severe regression on Debian on libc++ on mips* https://bugs.llvm.org/show_bug.cgi?id=43011 Simon found the regressor! Besides that, we look good. I will try to get a rebuild of the Debian archive with this version. Sylvestre ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
