clayborg added a comment.

In, @labath wrote:

> 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" 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?

lldb-commits mailing list

Reply via email to