[Lldb-commits] [lldb] [lldb] Support dSYMs as modules (PR #77966)

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Tue Jan 16 14:02:48 PST 2024


clayborg wrote:

> > > If a module is debug info only, like a dSYM file, and then you try to `target module add` it to a target, it would be nice to add it as the symbol file for an already existing module. The test below, I wouldn't want a target with two things representing a.out, which is what is happening. This can cause lookups to return less valuable results because we will always match `a.out` first, which has no debug info.
> > > Would it be better to be modify "target symbols add" to allow it to add the symbol file as a module if it returns `true` from a call to "ObjectFile::CanBeTargetModule(...)" but only if there are no matching modules to add the symbol file to?
> > 
> > 
> > @JDevlieghere Any comments on the above comment?
> 
> Your suggestion is to try `target symbols add <dSYM>` first when someone does `target module add <dSYM>` so that if a target module already exists, it's getting added there, as is the case in the test. If it doesn't, we do the same thing the test I added does (which I'll modify to not match the main module). I think that makes sense and can prevents users from accidentally doing the wrong thing. I'll see how easy/hard it would be to make that work at the command level. 👍

Yeah, in "target module add" we could test if the object file returns `eTypeDebugInfo` as the type, then if so we can add it as the symbol file for an object file, but it there isn't any match, fall back to just adding it as a module if the object file returns `true` from `ObjectFile::CanBeTargetModule()`.

The other way to do this is to do this work in `target symbols add` only and not allow `target module add` to work with symbol files.

https://github.com/llvm/llvm-project/pull/77966


More information about the lldb-commits mailing list