rchamala wrote: > > Looks fine to me but I'd wait on @jimingham to look at this before merging > > it since he brought up the issue. > > @medismailben Sure. To add some context on @jimingham's concern about finding > the right target per module: > > In the original implementation, I used FindModule to identify the owning > target for a given module. This works for standalone shared libraries (.so), > but fails for Android APK containers. The target's image list contains the > APK itself, but during symbol resolution LLDB expands the APK and discovers > the embedded shared libraries. When `LocateSourceFile` is later called with > one of these embedded .so modules, `FindModule` does not match it against the > APK entry in the target's image list, so the owning target is never found and > the locator is never invoked. > > Ideally, we would pass the TargetSP directly to `LocateSourceFile`, but the > target context is lost at the `PluginManager` boundary. My current solution is > > ``` > StackFrame (has Target) > → ApplyFileMappings (has TargetSP) > → PluginManager::LocateSourceFile(module_sp, file) ← > target dropped > → SymbolLocatorScripted::LocateSourceFile(...) ← no > target context > → ForEachScriptedTarget(...) ← > iterates all scripted targets > ``` > > I'm not sure if passing TargetSP through PluginManager would be a reasonable > change or a design violation, since PluginManager is stateless and > target-agnostic by design. Our callback ideally needs the owning target to > dispatch correctly. > > That said, this is not a problem in the majority of practical use cases. It > only matters when multiple targets have different scripted locators that > could resolve the same module differently — which is pretty rare IMO. > Although the callback is registered per-target, from a dispatch standpoint > `ForEachScriptedTarget` picks the first target that returns a valid result, > essentially ignoring it. Curious to hear your thoughts
https://github.com/llvm/llvm-project/pull/181528 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
