labath added a comment.

I can try to split the patch up a bit if you think it will make things easier.  
I'm not sure how much I will be able to do that, as the patch is not that big, 
it just needs to touch a bunch of files for the changed interfaces.

In, @clayborg wrote:

> Looks fine, a bit hard to tell exactly what is going on so I will accept as 
> long as the following things are still true:
> - each lldb_private::ObjectFile has its own section list that perfectly 
> mirrors exactly what is in that object file and that file alone

This part is not completely true. It is true for ObjectFileELF/COFF/JIT, and is 
enforced by the fact that the ObjectFile::GetSections does not even have access 
to the unified section list. However, it is *not* true for ObjectFileMachO (but 
that is not because of this patch). This is the problem I've had when trying to 
refactor this (and it's the reason the ObjectFileMachO<->SymbolVendorMacOSX 
interface is a bit weird). It seems that the ObjectFileMachO sometimes takes a 
section from the unified list and adds it to it's own list (or at least it 
appears to be doing that). I don't know enough about MachO to understand why is 
it doing that, or how to fix it. I've highlighted the places in the code where 
I think this is happening. Any suggestions would be welcome here.

> - The lldb_private::Module hands out a unified section list that is populated 
> by the symbol vendor where it uses one or more object files to create the 
> unified section list

This part is true.

Comment at: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1415-1416
           SectionSP unified_section_sp(
           if (is_dsym && unified_section_sp) {
Here we are grabbing a section from the unified section list.

Comment at: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1562
And here it gets added to the object file's section list.

lldb-commits mailing list

Reply via email to