relocation truncated to fit: R_ARM_PREL31

Hello all,

I've occasionally run into issues with the linker while building for the SparkFun MicroMod Teensy which, I believe, is analogous to the Teensy 4.0 for the purpose of discussion here (i.e. no difference in the linker script or MCU). I'm using PlatformIO to pull in the Teensyduino framework and facilitate compilation and program loading, but I have rewritten nearly all peripheral drivers, written several additional libraries, and heavily modified a multi-threading library, so little remains of the "Arduino" framework. I'm hoping this won't be a deal breaker for those who would like to provide assistance, and I understand it is rather difficult to help when there are so many unknowns in my case, but I am hoping to move the problem space away from my program in the concrete sense and into the more (or less) familiar area of linkers and the linking process.

And so, with that lengthy introduction to my first post anywhere on the internet, I'll hit you with a wall of linker errors with the details below.

Code:
# For convenience
toolchain_path=c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16

${toolchain_path}\libstdc++.a(system_error.o):(.ARM.extab.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in ${toolchain_path}\libstdc++.a(eh_personality.o)   
${toolchain_path}\libstdc++.a(system_error.o):(.ARM.exidx.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei'
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt17__throw_bad_allocv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt17__throw_bad_allocv'
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt19__throw_logic_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in ${toolchain_path}\libstdc++.a(eh_personality.o)
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt19__throw_logic_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt19__throw_logic_errorPKc'
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt20__throw_length_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against 
symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in ${toolchain_path}\libstdc++.a(eh_personality.o)
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt20__throw_length_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against 
`.ARM.extab.text._ZSt20__throw_length_errorPKc'
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt24__throw_out_of_range_fmtPKcz+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in ${toolchain_path}\libstdc++.a(eh_personality.o)
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt24__throw_out_of_range_fmtPKcz+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt24__throw_out_of_range_fmtPKcz'
${toolchain_path}\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt25__throw_bad_function_callv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt25__throw_bad_function_callv'
${toolchain_path}\libstdc++.a(cow-stdexcept.o):(.ARM.extab.text._ZNSt11logic_errorC2EPKc+0x0): additional relocation overflows omitted from the output
${toolchain_path}\libg.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\debug\firmware.elf] Error 1

(Note: I'm not sure what writer.c is, but I didn't write it.)

This is the second instance of this specific (and nearly identical) set of linker errors I have encountered with my code base. The first was earlier in my multi-threading library development which occurred only when I started a fresh project (with very few libraries pulled in) to run some tests. After some unsuccessful research and debugging, I abandoned the small project and returned to development on a project with more libraries.

I am familiar with ARM THUMB assembly, the finer aspects of C, and low level computer architectures in general, but there are many things I don't know. As far as I understand the error messages, the issue pertains to the limit of ARM branch instructions which requires relative branch targets to be within [-231, 231 - 1] bytes (+/-1GiB, signed 31 bit (2's compliment)). The symbols which are out of range (either the destination or the branch instruction, I'm not sure which) are related to C++ exception handling. However I have not had any success by compiling with the flag -fno-exceptions. As a sanity check, I have also tried replacing all instances of inline ASM instructions of relative branches to C functions with an equivalent LDR r0,=func and BX r0 to no effect as expected.

For reference:
https://developer.arm.com/documenta...ntrol-instructions/B--BL--BX--and-BLX?lang=en
https://stackoverflow.com/questions...rror-relocation-truncated-to-fit-r-arm-prel31 (Similar issue)

The crux of the issue is my confusion as to why this error would occur at all. This may be a result of the FLASHMEM code being located at 0x60000000. Looking at the i.MX RT1060 TRM and the Teensy 4.0 memory map graphic on the product page, has not really given me any further insight.

Here is the output of a similar build before my foray into the Serial drivers which seemed to be the trigger this time.

Code:
teensy_size: Memory Usage on Teensy MicroMod:
teensy_size:   FLASH: code:127508, data:44956, headers:8356   free for files:16334252
teensy_size:    RAM1: variables:53600, code:125784, padding:5288   free for local variables:339616
teensy_size:    RAM2: variables:12384  free for malloc/new:511904


Details:

Source code: No source code. (I don't believe this is relevant to the issue)
Error messages: See above. No other warnings from the compiler.
Hardware: SparkFun MicroMod Teensy on a MicroMod ATP carrier board (no other hardware)
Wiring: N/A
Software: Teensyduino, PlatformIO, Windows, Only custom libraries

Thanks,
Wesley Dahar
 
Sorry, it is sort of hard for anyone to give you in more specific advice versus the stackoverflow link mentioned.

That is, we do not see any of your code, nor linker scripts nor build line...
Also are you using same version of the GCC tool set as is used for the Arduino build?

But if it were me, I would build it using Arduino IDE, with verbose build turned on.

And compare the build options you are using versus the ones used in the Teensy build and see if anything jumps out.
 
Thanks for the suggestion Kurt. I'll see if I can get a build with an Arduino IDE for reference.

If by "build line" you mean toolchain and compiler arguments, then I'll add that (should be the default), but the linker script is the stock Teensy linker script.

That said I'm hoping to get some C/C++ linker gurus to weigh in on this because the problem seems to be with the linker and not with the code. And by that I mean the code itself is all legal C++ but the linker is having trouble reaching the exception handling routines. My suspicion is that the sufficiently large projects with lots of common dependencies (as is my case) will suffer from this because the code cannot be organized in such a way as to minimize the distance between all symbols. I'm hoping a potential solution would be something along the lines of adding an intermediate jump table to the linker to facilitate long jumps across code. I'm just making that up, but it sounds like a real thing, so I'll look into it as well.
 
Here we go: https://devblogs.microsoft.com/oldnewthing/20210616-00/?p=105314

I'm pretty sure the linker should already do this, and I can't imagine there would be a problem with the linker script if that were the case, but perhaps the C++ exception code is restricted to only using the direct branching instructions. If so, I'll have to do some digging as to why -fno-exceptions compiler argument did nothing. I've only been writing C++ for 2 months now, but I would hesitate to suggest that disabling exceptions is the answer to this and all similar issues.

Might take me a while to repackage my project into something Arduino can build, as well, so I might prioritize this for the moment.
 
Verbose build compilation command (output and source removed)

Code:
arm-none-eabi-g++
 -c
 -fno-exceptions
 -felide-constructors
 -fno-rtti
 -std=gnu++14
 -Wno-error=narrowing
 -fpermissive
 -fno-threadsafe-statics
 -fno-exceptions (duplicate: Looks like this was already part of the default compiler arguments for the platform)
 -Wall
 -ffunction-sections
 -fdata-sections
 -mthumb
 -mcpu=cortex-m7
 -nostdlib
 -fsingle-precision-constant
 -mfloat-abi=hard
 -mfpu=fpv5-d16
 -Og
 -g2
 -ggdb2
 -DPLATFORMIO=60104
 -D__IMXRT1062__
 -DARDUINO_TEENSY_MICROMOD
 -DTRACE
 -DUSB_SERIAL
 -DARDUINO=10805
 -DTEENSYDUINO=157
 -DCORE_TEENSY
 -DF_CPU=600000000
 -DLAYOUT_US_ENGLISH
 -D__PLATFORMIO_BUILD_DEBUG__
 -Iinclude
 -Isrc
 -I (x38 libraries...)
 -IC:\Users\wdahar\.platformio\packages\framework-arduinoteensy\cores\teensy4
 
Note, while I have worked on various GCC targets over the years, I've never worked on an ARM microprocessor (at the level of knowing the underlying instruction set, etc.)

But in general what typically happens with this type of an error, is that instructions on the machine have a limited number of bits to encode addresses and the linker has an address that does not fit in that limit.

For example on the PowerPC, direct calls and branches use an I-FORM instruction, which has a 6-bit opcode, 24-bit signed displacement, and 2-bit flag field. In the flag field, one bit says whether this is a jump or call instruction (call instruction puts the return address in the special LR register). The other flag field bit says the address is PC-relative or absolute (with PC-relative being the most common). Because all instructions must be 32-bit aligned, the bottom 2 bits are left off. This means the address being called must be within 2**25 bytes of the current instruction (2**23 32-bit words). If the address doesn't fit within that size, the linker complains.

There are various ways around this limitation. For example, for calls, the linker might create a thunk, which is close enough for the call, that loads up the address from a table (typically called GOT or PLT) and jumps to that address.

One thing that can cause this error is if you call a symbol that you think is a function, but it is actually a data item, and the location where static/global variables are put is logically in a different address space. Alternatively, perhaps a linker map is told that a particular function is at a given location.
 
One thing that can cause this error is if you call a symbol that you think is a function, but it is actually a data item, and the location where static/global variables are put is logically in a different address space. Alternatively, perhaps a linker map is told that a particular function is at a given location.

That is not something I had considered, but it would make a lot of sense. I'll definitely check for that in my code. Even if that doesn't end up being my specific issue, I'm glad you brought it up, because I might run into it in the future. Thanks,
 
That is not something I had considered, but it would make a lot of sense. I'll definitely check for that in my code. Even if that doesn't end up being my specific issue, I'm glad you brought it up, because I might run into it in the future. Thanks,

If it is a function that located in a location you can't get to via a single call instruction, I believe the ARM GCC supports declaring the function with the longcall attribute. If you call such a function, the compiler will generate longer code to call it:

 
And another reason you might get the error is just the program is so large that the address limits are too small.

For example, in the development of GCC for the power10, two of the Spec 2017 benchmarks (521.wrf_r and 621.wrf_s, which essentially is the same program) had one Fortran function that was larger than the size that a conditional jump can reach. The compiler has to rewrite the jump to reverse the test, and do a jump +8 if the original test would have failed, and the word after the conditional branch would be an unconditional jump, which has a longer range. Some of the new instructions in power10 were larger, and at the time, GCC was not accounting for those differences, and did not properly do the reverse conditional test around an unconditional jump.
 
Although it doesn't exactly match my issue, this concise thread addresses a similar case of R_ARM_PREL31: https://community.nxp.com/t5/i-MX-R...ker-error-ARM-exidx-0x0-relocation/m-p/981181

I did a grep through my object files for instances of '__throw_' just to see where these exceptions are coming from and found that a majority of them are inlined by various std::string methods, as revealed by the disassembly of several of my libraries.

So far as I understand, the R_ARM_PREL31 linker error indicates that a certain branch instruction cannot reach its target due to the address range limit of a 31 bit signed PC relative offset. In my case, the ARM.exidx section is the target for all C++ exceptions, but this section is located in ITCM (0x00000000) which is too far away from some of the code residing in PROGMEM (0x60000000) where the problematic exceptions likely originate from. It seems that the Teensy platform compiles with the flag -fno-exceptions by default, but the compiler used by the PlatformIO flavor of the Teensy platform (gcc-arm-none-eabi 5.4.1) comes with the C++ standard library full of exception ridden code (which makes sense).

There area few solutions I'm considering at this point:

1) I must remove all instances of standard library code which use exceptions
2) I can move the ARM.exidx section to flash and make sure all exception code resides in PROGMEM
3) I can optimize for code size and hope the linker will always be able to find a near enough location for exception code
4) I can look for a compiler with a C++ standard library that doesn't use exceptions (No sure about that one)
5) I could catch all exceptions explicitly (I prefer sanitized inputs to handling errors, and I don't care about OOM here, so I don't really have exception handling in my code... And I'm skeptical that catching the exception would actually remove the problematic branching code.)

I've received some good insight on this and it really helped me understand the problem. I'll try and get that Arduino IDE build soon.
 
This sort of error used to be common a couple years ago, long before MicroMod, and most importantly before this patch to the linker scripts.

https://github.com/PaulStoffregen/cores/commit/2f8568659cb7553ca12e5ca2d0358df9d30427a6

Any chance you've edited the linker script? Deleting or moving .ARM.exidx elsewhere leads to these sorts of problems. Frank in particular wanted it moved out of ITCM so we don't waste any RAM. FWIW, I want that too... but we never found a way to do it without these sorts of errors. Several tests shows it usually adds only small overhead, so I made the decision to just live with a small amount of wasted memory (unless someone finds a proper solution).

Maybe it will get revisited when we someday update to a newer toolchain and rebuild the C library.
 
Sorry, I've encountered this with the original linker script and I've seen no noticeable difference when either removing the ARM.exidx section entirely or simply moving it to flash. I started to transfer my project to an Arduino sketch, and as exciting as that sounds, I'm now leaning toward recompiling the toolchain with exceptions disabled (Looks like the Arduino IDE also has exceptions enabled from what I've seen). I think no matter how I rearrange the sections in the linker, I'll eventually hit this wall again as the project grows. I'll post another update after rebuilding gcc.
 
Can you compose a small program which reproduces this error when copied into Arduino 1.8.19 and Teensyduino 1.57, using the linker script and libraries Teensyduino 1.57 provides?
 
It's a little difficult to make a small program which suffers from the same issues as a large program... I'd need to get a whole lot of code to do it with the original linker script, but I wrote this to work with a modified linker script which put the PROGMEM section at a further address. I did not see the linker error.

Code:
#include <string>
#include <cstdint>

extern "C" {
uint32_t _stext;     // ADDR(.text.itcm)
uint32_t _etext;     // ADDR(.text.itcm) + SIZEOF(.text.itcm) + SIZEOF(.ARM.exidx)
uint32_t _stextload; // LOADADDR(.text.itcm)
}

__attribute__((section(".progmem")))
void string_append(std::string &string) {
  string.append("This has the potential to throw an exception");
}

void setup() {
  std::string string;
  string_append(string);
  Serial.printf(
    ".text.itcm  %010p (start address)\r\n"
    ".text.itcm  %010p (load address)\r\n"
    ".ARM.exidx  %010p (end address)\r\n"
    "string_append(): %010p\r\n",
    &_stext,
    &_etext,
    &_stextload,
    string_append
  );
}

void loop() {
}

// Output:
//
// .text.itcm  0x20003594 (start address)
// .text.itcm  0x20003590 (load address)
// .ARM.exidx  0x20003598 (end address)
// string_append(): 0x60800699
//
 
I hope you can understand my opinion regarding not reproducing the error in unmodified Arduino+Teensyduino...

FWIW, the code in msg #14 prints incorrect output. This is needed for correct results:

Code:
extern "C" {
extern uint32_t _stext;     // ADDR(.text.itcm)
extern uint32_t _etext;     // ADDR(.text.itcm) + SIZEOF(.text.itcm) + SIZEOF(.ARM.exidx)
extern uint32_t _stextload; // LOADADDR(.text.itcm)
}
 
Oh! You're right. I forgot to include some things when I rewrote that from another one of my libraries.

And yes, I understand the need for repeatability. This remains my problem until such a time as I can make it into someone else's problem. Everyone's advice has been very much appreciated and I understand that what others freely offer is at the expense of their own time and generosity.
 
It's a little difficult to make a small program which suffers from the same issues as a large program... I'd need to get a whole lot of code to do it with the original linker script, but I wrote this to work with a modified linker script which put the PROGMEM section at a further address. I did not see the linker error.

I don't know if this will help, but I have used the macros below when I want to make a program artificially large

Code:
#define LARGE_ARRAY_TEST (0)	// 1 = define large array to increase code size

#if (LARGE_ARRAY_TEST)
// nested arrays of integers to add code size for testing 
#define A0 { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15}  // 16  elements 64
#define A1 {A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0,A0}  // 256 elements 1KB 
#define A2 {A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1,A1}  // 4K  elements 16KB
#define A3 {A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2,A2}  // 64K elements 256KB 
#define A4 {A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3,A3}  // 1M  elements 4MB

// const variables reside in flash and get optimized out if never accessed
// use uint8_t -> 1MB, uint16_t -> 2MB, uint32_t -> 4MB, uint64_t -> 8MB)
PROGMEM const uint8_t a[16][16][16][16][16] = A4;
#endif

then put in something to access the array to prevent it from being optimized out

Code:
#if (LARGE_ARRAY_TEST) // if true, access array so it doesn't get optimized out
  serial->printf( "Large Array Test -- %08lX\n", (uint32_t)&a[15][15][15][15][15] );
#endif
 
luni, It could be that I'm only seeing different errors because additional relocation errors were suppressed, but thanks for the link. I'm hoping that rebuilding libstdc++.a with exceptions disabled will clear things up. That will be tomorrow's problem.
 
I don't know if this will help, but I have used the macros below when I want to make a program artificially large
...
then put in something to access the array to prevent it from being optimized out
[/CODE]

Way ahead of you Joe. I actually saw your code yesterday and was inspired. Unfortunately the gains were not quite as scalable. Or maybe I just didn't want to deal with C pre-processor stringification...

I was trying something similar before giving up and just relocating the section in the linker script. I'll keep trying to reproduce, but I just wanted to get something out quickly.

The functions return pointers to themselves to avoid being optimized out.

Code:
#define FN(a) __attribute__((section(".progmem"))) void *fn_ ## a(void) { return (void *) &fn_  ## a; }

FN(0) FN(1) FN(2) FN(3) FN(4) FN(5) FN(6) FN(7) FN(8) FN(9)
...
FN(60) FN(61) FN(62) FN(63) FN(64) FN(65) FN(66) FN(67) FN(68) FN(69)
#undef FN
#define FN(a) __attribute__((section(".progmem"))) void *fn_ ## a ## 2(void) { return (void *) &fn_  ## a ## 2; }
FN(10) FN(11) FN(12) FN(13) FN(14) FN(15) FN(16) FN(17) FN(18) FN(19)
...
 
Way ahead of you Joe. I actually saw your code yesterday and was inspired. Unfortunately the gains were not quite as scalable. Or maybe I just didn't want to deal with C pre-processor stringification...

I was trying something similar before giving up and just relocating the section in the linker script. I'll keep trying to reproduce, but I just wanted to get something out quickly.

The functions return pointers to themselves to avoid being optimized out.
All modules are compiled with -ffunction-sections -fdata-sections and the linker is passed --gc-sections which means that the linker will delete functions and global data that aren't referenced.
 
All modules are compiled with -ffunction-sections -fdata-sections and the linker is passed --gc-sections which means that the linker will delete functions and global data that aren't referenced.

Fair enough. I usually don't try to outsmart the compiler or the linker, but I thought this might have worked. I did see an increased compiled binary size as I added more instances of my function, but it's not a big deal at this point. And, actually, I shouldn't have been putting those functions in PROGMEM, since that doesn't reflect my failing code. There was a lot I could have don better in that example, but I don't think this is a trivially reproducible issue to begin with.
 
The toolchain used by the Teensyduino framework on PlaformIO is provided by the xPack project. I found this very brief discussion (from 5 days ago) which concerns their build of the C standard library and, more specifically, it having been compiled with exceptions always enabled. Apparently, the subsequent compilation of projects with either flavor of -f[no-]exceptions should use different precompiled libstdc++ (or something to that effect). I don't have any idea how long this has been an issue, but as of 3 days ago the latest release suggests the issue is resolved. Although the original complaint was related to code size, I find that this also addresses my issue in a roundabout way.

https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/discussions/23

So it seems like the libc in the official ARM release respects whether I use -fno-exceptions or not, but the xpack version forces -fexceptions to be on.

I cloned the Teensy platform project in PlatformIO, modified the version of the toolchain-gccarmnoneeabi to latest and rebuilt my project using the custom platform. Now I'm down to one linker error which complains about a missing math library, which doesn't look like a big deal.

Code:
Linking .pio\build\debug\firmware.elf
c:/users/wdahar/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -larm_cortexM7lfsp_math
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\debug\firmware.elf] Error 1

That being said, I would much prefer to be able to use the toolchain version in line with the official Teensyduino release, and I'm still interested in finding a solution to the original linker errors. I might sit down and do some more thorough investigation now that I have a workable solution.
 
Before I get ahead of myself... I just realized that the linking process might have simply stopped when it couldn't find the library. I just decompiled one of my libraries and found refererences to '_ZSt20__throw_length_errorPKc' and the like. Ugh.

Oh and the latest version on PIO is also 5 months old. I really jumped the gun here. Sorry.
 
I finally converted my code into an Arduino compatible structure (PlatformIO and Arduino differ on library structure and metadata files). Same errors.

Code:
Arduino: 1.8.19 (Windows 10), TD: 1.57, Board: "Teensy MicroMod, Serial, 600 MHz, Debug, US English"

c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(system_error.o):(.ARM.extab.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(eh_personality.o)
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(system_error.o):(.ARM.exidx.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNKSt3_V214error_category10_M_messageB5cxx11Ei'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt17__throw_bad_allocv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt17__throw_bad_allocv'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt19__throw_logic_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(eh_personality.o)
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt19__throw_logic_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt19__throw_logic_errorPKc'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt20__throw_length_errorPKc+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(eh_personality.o)
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt20__throw_length_errorPKc+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt20__throw_length_errorPKc'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.extab.text._ZSt24__throw_out_of_range_fmtPKcz+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(eh_personality.o)
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt24__throw_out_of_range_fmtPKcz+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt24__throw_out_of_range_fmtPKcz'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(functexcept.o):(.ARM.exidx.text._ZSt25__throw_bad_function_callv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt25__throw_bad_function_callv'
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libstdc++.a(cow-stdexcept.o):(.ARM.extab.text._ZNSt11logic_errorC2EPKc+0x0): additional relocation overflows omitted from the output
c:/program files (x86)/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/fpv5-d16\libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
collect2.exe: error: ld returned 1 exit status

Error compiling for board Teensy MicroMod.
 
Back
Top