[Lldb-commits] [PATCH] D42955: Make Module::GetSectionList output consistent

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D42955#1026197, @labath wrote:

> In https://reviews.llvm.org/D42955#1026175, @clayborg wrote:
>
> > The dSYM file is a mach-o file that contains symbols only, It is because the dSYM file (stand alone debug info file) has all of the section definitions from the main executable, but no section content for everything except the DWARF debug info. The DWARF only exists in the dSYM file. The dSYM file also has all of the symbols as it gets made before the executable is stripped. Many symbols refer to a section by section index, so that is why we must have the section definitions in the dSYM file. So the dSYM wants the sections from the main executable so it can access __text and __data if needed since symbol refer to these and someone might ask a symbol from a dSYM file what its instructions are. So the dSYM uses the real sections from the main executable file instead of its own.
>
>
> I see, thanks for the explanation. The code makes more sense now.
>
> But now I have another question. Is this an intentional design decision that we want to preserve; or just how things happen to work now, and should be cleaned up in the future (to achieve the "ObjectFile contains only own sections" invariant)?


Intentional, but it is up to the SymbolVendor subclass to do all of this. We want the data from the dSYM to be useful and since the dSYM really is a companion debug info file, it needs info from elsewhere to be complete.

> I'm asking this, because if it's the former then this patch probably needs to be redone, as it tries to enforce that invariant (and then needs to jump through hoops to enable the ObjectFileMachO use case). OTOH, if it's the latter, then I think this is a step in the right direction, as it makes it obvious that ObjectFileMachO is doing something that it shouldn't (and at the same time it makes it harder for other ObjectFiles to do the same).

It should be doing it. Again, the symbol vendor is the one that is trying to make everything fit together and "just work".

> BTW, the same situation (symbol file containing empty section definitions for code&data) can happen on elf targets as well (if the symbol file is produced with `strip --only-keep-debug`), but everything seems to be working fine, presumably because all consumers are accessing the sections through the unified section list.

Exactly. I see any good debug info format not needing to duplicate things that might be in another file. The symbol vendor under the covers, creates a unified experience for all consumers of the Module that contains the symbol vendor, so it is something that we want to encourage and allow. So ObjectFileMachO isn't doing anything wrong. Feel free to update the design if needed?


https://reviews.llvm.org/D42955