I'm currently working on bringing up the Rust target thumbv7m-unknown-linux-uclibc. I believe I have worked through the majority of the Rust related compiling and linking issues, and am now running into a post-linking issue. The uClinux environment wants executables in a specific format bFLT and provides a tool elf2flt for transforming ELFs to bFLTs. Right now the elf2flt utility is not very pleased with the object files Rust is handing it. Some days elf2flt complains about "non-fully-resolved input file". Other days it complains about "overlapping .text and .data sections".
Is there anyone out there with experience guiding Rust objects through elf2flt? Maybe @japaric? I see some level of support for mips-unknown-linux-uclibc and I'm assuming that elf2flt was wrangled as part of landing that target.
First off, thanks for working on bringing up that target, that's exciting.
Can you post an example of an ELF file you've fed elf2flt? The two errors you mention could occur if you're handing it .o or .a files, which are not fully linked/relocated, but should not occur in standalone executable files. (I believe the bFLT format is only used for executables and not intermediate build products, but it's been a couple years since I looked seriously at it.)
Okay. I don't have a clean diagnosis, but I can give some context in case it's helpful.
0x21fe8 is the start of your .rodata section. 0x1d88c is nothing in particular -- it's an address in the .text section that also happens to be within the ARM EXIDX region, which is used for exception unwinding.
The first thing I would try would be to see if you can get the linker to not generate the EXIDX PHDR (PHDR #0), because it definitely is some data overlapping text with different properties (no-execute) and might be confusing the tool. You can probably do this by editing the linker script, or (for experimental purposes) by directly editing the ELF binary. The loaded segment appears to be entirely redundant; I assume it has an ABI purpose on ARM ELF targets.
(Note that removing the PHDR / segment for EXIDX is different from removing the .ARM.exidxsection, which I wouldn't recommend unless you've got unwinding disabled. The .ARM.exidx is covered by the normal text PHDR/segment (PHDR #1)).
Thanks for that tip! Do you have any ideas on how to either remove that segment or get the linker to not generate it? I was looking at objcopy but it appears to only support removing sections, not segments. It is also not entirely clear where that particular header/segment is defined in the linker script, or if it is even explicitly defined at all.
Have you tried building with panic=abort as a test? That might be enough to suppress generation of the exception unwinding tables, unless you're linking in some C(++).
Ok I was able to get around the problem, though through very different means. It turned out that the toolchain shipped with an elf2flt.ld linker script which it seems was meant for use alongside the elf2flt tool. Using that linker script has moved me past the over lap errors into a whole new world of relocations which elf2flt isn't happy with. The fun of new targets haha.