labath added a comment.

In, @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" 

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.

lldb-commits mailing list

Reply via email to