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

Reply via email to