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@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
