labath added a comment. 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)? 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). 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. https://reviews.llvm.org/D42955 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
