[lldb-dev] Are overlapping ELF sections problematic?

[Zdenek Prikryl via lldb-dev]

Hi Pavel, Thomas,

Just a note that this topic is repeating now and then. It'd be nice to 
have a concept at least. We can go with an additional argument, or 
enhance addr_t, or enhance Address, or create a new type for it. So, 
some sort of discussion that would clarify the concept a little bit is 
welcome, I think.

Best regards.

On 6/3/19 1:21 PM, Pavel Labath via lldb-dev wrote:
> On 03/06/2019 10:19, Thomas Goodfellow via lldb-dev wrote:
>> I'm working with an embedded platform that segregates memory between
>> executable code, RAM, and constant values. The three kinds occupy
>> three separate address spaces, accessed by specific instructions (e.g.
>> "load from RAM address #0" vs "load from constant ROM address #0")
>> with fairly small ranges for literal address values. So necessarily
>> all three address spaces all start at zero.
>>
>> We're using the LLVM toolchain with ELF32 files, mapping the three
>> spaces as.text, .data, and .crom sections, with a linker script
>> setting the address for all three sections to zero and so producing a
>> non-relocatable executable image (the .text section becomes a ROM for
>> an embedded device so final addresses are required). To support
>> debugging with LLDB (where the GDB server protocol presumes a single
>> flat memory space) the sections are mapped to address ranges in a
>> larger space (using the top two bits) and the debugger stub of the
>> platform then demuxes the memory accesses to the appropriate address
>> spaces).
>>
>> Until recently this was done by loading the ELF file in LLDB, e.g:
>> "target modules load --file test.elf .data 0 .crom 0x40000000 .text
>> 0x80000000". However the changes introduced through
>> https://reviews.llvm.org/D55998 removed support for overlapping
>> sections, with a remark "I don't anticipate running into this
>> situation in the real world. However, if we do run into it, and the
>> current behavior is not suitable for some reason, we can implement
>> this logic differently."
>>
>> Our immediate coping strategy was implementing the remapping in the
>> file parsing of ObjectFileELF, but this LLDB change makes us
>> apprehensive that we may start encountering similar issues elsewhere
>> in the LLVM tooling. Are ELF sections with overlapping addresses so
>> rare (or even actually invalid) that ongoing support will be fragile?
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> Hi Thomas,
>
> I can't say what's the situation in the rest of llvm, but right now 
> lldb has zero test coverage for the flow you are using, so the fact 
> that this has worked until now was pretty much an accident.
>
> The reason I chose to disallow the overlapping sections in the patch 
> you quote was because it was very hard to say what will be the meaning 
> of this to the upper layers of lldb. For instance, a lot things in 
> lldb work with "file addresses" (that is, virtual address, as they are 
> known in the file, without any remapping). This means that the 
> overlapping sections become ambiguous even though you have remapped 
> them to non-overlapping "load addresses" with the "target modules 
> load" command. For instance, the result of a query like 
> "SectionList::FindSectionContainingFileAddress(lldb::addr_t)" would 
> depend on how exactly was the search algorithm implemented.
>
> I believe that a long term solution here would be to introduce some 
> concept of address spaces to lldb. Then these queries would no longer 
> be ambiguous as the function FindSectionContainingFileAddress would 
> (presumably) take an additional address-space identifier as an 
> argument. I know this is what some downstream users are doing to make 
> things like this work. However, this is a fairly invasive change, so 
> doing something like this upstream would require a lot of previous 
> discussion.
>
> In the mean time, I believe you can just patch out the part which 
> drops the overlapping sections from the section list and get behavior 
> which was more-or-less identical to the old one. However, I can't 
> guarantee that nothing else will break in this scenario. I also 
> wouldn't be opposed to making some change to this logic upstream too, 
> if we can come up with some consistent story as to what exactly this 
> means.
>
> regards,
> pl
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-- 
Zdenek Prikryl
CTO
T +420 541 141 475
Codasip.com