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

[Greg Clayton via lldb-commits]

> 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.
> 

I think having the program header segments being top level sections in ELF, with the sections headers contained within them would fix things correctly and allow us to give out as section + offset base address. 

> Does MachO enforce somehow that every section is fully contained in one segment?

yes


> 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.

I would be surprised to see this kind of thing, though it could exist. We can easily just make two top level sections when this happens so it can remain consistent?

> 
> 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.

I agree, LOAD segments would be created, and any sections that would fit inside of those will be put there, otherwise, they are top level sections?
> 
> 
> 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?

That is the key question.

> 
> pl