relocation truncated to fit: R_ARM_PREL31

PaulStoffregen said:
Any chance you'll give us (hopefully reasonably small) code to reproduce this error in Arduino+Teensyduino?
Click to expand...

I would like to be able to reproduce this as well, and I know it would mean a lot for current and future testing if there was a quantitative means of measuring this issue.

I'm thinking that in order to reproduce the issue, a program would have to contain sufficient code so as to leave the linker with no hope of locating one or more C++ exceptions within range of the ARM.exidx section. This would not only mean that the code must be large and thwart the linker's attempts at optimization but also that code must uniformly distribute exceptions so that the linker cannot shuffle basic blocks around. I think most of us have already reached a similar, if not identical, set of requirements, but the implementation is not something I'm confident of. I'm not giving up, but it's not exactly a priority for me right now.

It seems the easier approach would be to build using a toolchain that has exceptions disabled, through and through. Given that this is a non-issue for nearly all projects, anyone else who finds themselves in this situation would likely be fine with that as well.

I've now compiled with both the latest xPack toolchain on PlatformIO (not sure which gcc version) and the 11.3.1 release which is only 3 days old and which was mentioned to have addressed the -fno-exceptions issue. I still get the same linker errors, but I might revisit 11.3.1. The newer compiler did catch a few new warning which is always nice.

I have been attempting to build libstdc++ out of tree with exceptions disabled, but it's slow going. I'm not all that experienced with these sorts of things yet. I'll probably end up just rebuilding the full toolchain, since that seems to be a prerequisite step anyway.

If all else fails, I may have to enable exceptions and handle exceptions from the standard library in a reduced number of translation units so that the linker can shuffle them within range of the ARM.exidx section. I'd have to wrap the collections and remove a lot of potential for inlining, and, even then, I wouldn't be able to guarantee that the linker will not perform inlining.

I'm really sorry to drag this out, especially when the issue is very much localized to my project. I'm not expecting a team effort here, and I mean that in the best possible sense. You all have been more than helpful, given this set of circumstances. I'm hoping this will either be a good reference for future readers or a cautionary tale for those who are too quick to blame the compiler. Which one it will be remains to be seen.
 
I've found that moving PROGMEM to ITCM instead of FLASH will resolve the linker errors related to the C++ exceptions. I sort of expected that would be the case, but I'm not too sure what to make of it going forward.

I fixed the remaining linker error by including the following:

Code: 
extern "C" int _write(){return -1;}

Code: 
c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi@1.50401.190816/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libg.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'

This seems to be a recurring issue if you search through the forum here, and I'm disappointed that it seems to be the recommended solution, but that's unrelated to this thread.

When I get a working build of libstdc++ with exceptions disabled, I'll update this thread.

Note that while I can successfully compile and link, the code does not run on the Teensy since I'm sure there are side effects to the relocation of PROGMEM.
 
I've been following the 1.58 beta thread and tired Paul's linker script update on the old 5.4.1 toolchain (https://forum.pjrc.com/threads/7104...olchain-trial)?p=312378&viewfull=1#post312378). It fixed most of the issues.

Code: 
c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi@1.50401.190816/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: .ARM.exidx has both ordered [`.ARM.exidx.text._ZNSt8__detail15_List_node_base9_M_unhookEv' in c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi@1.50401.190816/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(list.o)] and unordered [`.ARM.extab.text._ZSt17__throw_bad_allocv' in c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi@1.50401.190816/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o)] sections
c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi@1.50401.190816/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: final link failed: Bad value
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\debug\firmware.elf] Error 1

I then moved to the latest xPack (11.3.1) in platformIO with the linker script update and was able to compile, link, and upload.

As for my toolchain rebuild with exceptions disabled, I have been having trouble getting any toolchain built for my windows host. I was able to build a native cross compiler on linux, but I'll have to wait for better documentation from who-knows-where before I can address the plethora of errors I'm getting in the Windows build. I'll save that headache for another day.

I really appreciate the input from everyone here, and I think my issue has been satisfactorily resolved. Thanks.
 
Last edited:
You must log in or register to reply here.
Back
Top