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
