[lldb-dev] Are overlapping ELF sections problematic?

Tue Jun 4 03:21:33 PDT 2019

Hi Zdenek

In an ideal world  LLVM and LLDB would support a common approach for
address spaces. Currently our LLVM backend doesn't yet support address
spaces anyway, e.g. access to a variable declared as constant data:

const int my_val __attribute__((section (".crom"))) = { 42 };

is only possible from assembler code. Since current code already
features a blend of C and assembler this limitation is cumbersome
rather than catastrophic, but of course we expect to add proper
lowering for such addresses, so we're certainly interested in this
domain.

The work already done in coupling LLDB more closely to LLVM is obvious
(e.g. migrating from duplicated utility code) but the backends still
seem a little disjoint, e.g. some targets specify the same
architectural attributes such as registers in both projects. It would
be nice if a new (?)  feature like address spaces was added in a way
that minimised redundancy.

Cheers,
Tom

On Mon, 3 Jun 2019 at 15:08, Zdenek Prikryl <prikryl at codasip.com> wrote:
>
> 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
>