clayborg wrote:
> > This seems like a generic module loading observer. I don't see anything JIT
> > specific about it. Not saying a generic module loading observer is not a
> > good idea. But calling it a JITLoader seems pretty confusing to me.
>
> +1 on the name. The design seems very general, so maybe calling it something
> like ModuleObserver or something would make more sense.
>
> Your PR summary describes what users can do, but why might they want to do
> it? Do you have a motivation for this change?
I do, and I should have mentioned this in the description: I want to extend the
JITLoader API to be able to lazily resolve addresses. Right now JIT loaders are
inefficient and expensive to use as they must stop anytime something has been
JIT'ed and if a program JITs a million functions, we will stop a million times
due to it setting a breakpoint in the process. I changed it so that any "load
address -> lldb_private::Address" resolving goes though
`Target::ResolveLoadAddress()` with:
```
commit c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb
Author: Greg Clayton <gclay...@fb.com>
Date: Tue Jan 14 20:12:46 2025 -0800
[lldb][NFC] Make the target's SectionLoadList private. (#113278)
Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.
```
With this in, we can modify the `Target::ResolveLoadAddress` function like:
```
bool Target::ResolveLoadAddress(addr_t load_addr, Address &so_addr,
uint32_t stop_id, bool allow_section_end) {
bool result = m_section_load_history.ResolveLoadAddress(stop_id, load_addr,
so_addr, allow_section_end);
if (!result) {
// Check with JITLoader plug-ins and ask if they can resolve this address
lazily.
...
}
return result;
}
```
This allows JIT loaders to be loaded with little or no cost until we do a
backtrace. Any frames that go through JIT'ed functions that are not resolved
allows the JIT loaded to load only what is needed.
Another future patch will notify the JITLoader plug-ins about breakpoints as
they are created and allow the JIT loader to intelligently implement
functionality to set breakpoints. We have an internal JIT solution that already
does this. When a user sets a file and line breakpoint, or a breakpoint by
name, the JIT loader will mark up its metadata and stop in the debugger when
the code for this file and line breakpoint or breakpoint by name gets JIT'ed.
Again, this helps us debug processes that JIT without the huge overhead that
the current model imposes.
This patch lays the groundwork for current JITLoader plug-ins in python, and
will allow me to modify the JITLoader API and test the new changes in python.
It will allow me to break up the new changes piece by piece:
- JITLoader being able to lazily resolve functions as needed when a backtrace
happens without needing to have a breakpoint set all the time
- JITLoader getting knowledge of breakpoint creation to allow breakpoints to be
intelligently implemented by the JIT loader plug-in
@jimingham Hopefully this explains why this patch exists. I will read your
comments above and comment if needed.
https://github.com/llvm/llvm-project/pull/142514
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
