[Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Jim Ingham via lldb-commits]

In MachO a segment fully contains its sections and a section can only be in one segment.  I don't remember how much the lldb Section nesting code enforces this.  It would be weird to have two Sections at the same level overlap, I don't see any "GetSectionsForAddress(lldb::addr_t address)" API's so I don't think we're ready to handle that.

Maybe we could start marking sections as "duplicate" and only handing out the original one when doing lldb::addr_t -> Section lookups?

Jim


> On Dec 11, 2018, at 11:58 AM, Pavel Labath <pavel at labath.sk> wrote:
> 
> On 11/12/2018 20:39, Jim Ingham wrote:
>> Sections can have parents.  In MachO the text and data sections are actually contained in the TEXT and DATA segments respectively.  LLDB represents this by having an lldb_private::Section for the segment, and then all the sections in that segment are children of the parent Section (the MachO segment).  All the code that looks up addresses expects to potentially traverse this hierarchy.
>> It seems to me that what you are describing should fit in the nesting model?
>> Jim
>>  
> 
> Hmm.. that's an interesting idea. I'll have to think about that.
> 
> Does MachO enforce somehow that every section is fully contained in one segment? Because while that is true for elf in general, it is not a requirement, and it is possible to create functional executables (though I think I would have to use a hex editor for that) where one segment contains only a half of some section. But that might not be a big issue, as I think most tools will choke on files like this, so if we do something suboptimal here, it shouldn't be too bad.
> 
> The other hickup I can think of is that sometimes (and this happens in perfectly valid files too) one section is present in multiple segments. For example .eh_frame will be present in a "LOAD" segment (so it ends up in memory), but it will also be present in a special "GNU_EH_FRAME" segment (not sure why, but I guess it's to make it easier for someone to find it). But I think I can get around that by only creating these "container" sections for LOAD segments.
> 
> 
> The part I know nothing about is whether something similar could be done for PE/COFF files (and I'll need something like that there too). Adrian, Zachary, what is the relation ship between "image base" of an object file and its sections? Is there any way we could arrange so that the base address of a module always belongs to one of its sections?
> 
> pl