sketches fail to link with R_AVR_13_PCREL due to interrupt service routine too far for startup rjmp in vector [imported]

[cmaglie]

This is Issue 1071 moved from a Google Code project. Added by 2012-10-15T00:12:57.000Z by Xarq...@gmail.com. Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Write large program on Mega2560 with Arduino IDE 1.0.1 (typically with lots of library code)
2. Get unlucky with linker placement of code making interrupt service routine too far from location 0.
3. Get link error in the startup code: "c:/arduino-1.0.1/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6/crtm2560.o: In function __vector_default': (.vectors+0x5c): relocation truncated to fit: R_AVR_13_PCREL against symbol__vector_23' defined in .text.__vector_23 section in core.a(wiring.c.o)"

What is the expected output? What do you see instead? It should link properly, wiring.c and crtm2560.o haven't been modified and the user hasn't done anything wrong.

What version of the Arduino software are you using? On what operating system? Which Arduino board are you using? Arduino 1.0.1 on Windows 7 with Arduino Mega2560 board.

Please provide any additional information below. Google for "R_AVR_13_PCREL crtm2560" and see others have reported this (and mention regressing to Arduino 1.0.0 fixes it). Since the crtm2560.o appears to have "jmp 0", but the compiled elf executable appears to have "rjmp 0 ; nop" perhaps this is a linker optimization causing this problem? I am reporting this for a user on freenode IRC #arduino channel, so I cannot post full source (and I could see this being hard to replicate as adding or removing "random" lines of code can make it crop up or disappear).

[benelot]

Yes I have exactly the same problem. I don't use any libraries, my code was running for hours and now I get a similar error as this one, just some different numbers at R_AVR_XX_PCREL and __vector_XX as well as .vectors+0xXX. But this is the same error. As I found it reported on other pages and as I tested myself, this error is reproducable with Arduino 1.0.1 and Arduino 1.0.3 on Winows, but does not happen in Arduino 1.0. There my code compiles perfectly. In the forums (http://arduino.cc/forum/index.php?topic=140667.0) one proposes a workaround which actually removes the error, but then the program compiles but does not run anymore. I am working with Arduino 1.0 now as the error is gone for the moment.

[cmaglie]

Can you provide a test sketch that reproduce the problem? C

[benelot]

The problem disappeared again misteriously, but as soon as I have the bug again, I will give you a test sketch. I am back working on the newest version of the arduino editor (1.0.3) When I got the problem, I just switched back to 1.0 for a while and the error disappeared again. I think the error seems not to be on a clear code base. I did not change the code that much and it seemed to work again. I will come back as soon as I know more.

[benelot]

http://db.tt/zBycjgsK I uploaded a sketch that causes this problem in arduino IDE 1.0.1 but somehow not anymore in 1.0.3. I could not shorten it down, because it makes the bug disappear sometimes. I will upload another file as soon as I get the same error in 1.0.3

[benelot]

I get the error: In function __vector_default': (.vectors+0xcc): relocation truncated to fit: R_AVR_13_PCREL against symbol__vector_51' defined in .text.__vector_51 section in core.a(HardwareSerial.cpp.o)

[benelot]

http://db.tt/DcwiI8aW I uploaded another code that does compile in 1.0.1 but not in 1.0.3. Error:c:/users/qian/desktop/arduino-1.0.1-windows/arduino-1.0.3/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6/crtm2560.o: In function __vector_default': (.vectors+0x90): relocation truncated to fit: R_AVR_13_PCREL against symbol__vector_36' defined in .text.__vector_36 section in core.a(HardwareSerial.cpp.o)

[benelot]

I am working on an Arduino Mega if this is important.

[PaulStoffregen]

This appears to be a bug in the linker.

http://sourceware.org/bugzilla/show_bug.cgi?id=13410

I was able to reproduce the problem with a Teensy++ 2.0 board and a very large program which has many F() strings.

I just downloaded the source for binutils 2.23.2, ran "./configure --target=avr" then "make". I copied ld/ld-new to hardware/tools/avr/bin. The freshly compiled copy is not able to find the linker scripts. I solved this with "ln -s ../lib/avr/lib/ldscripts/" in the hardware/tools/avr/bin directory. It is able to successfully compile and when I upload, the program seems to run without errors. This was only a quick test on Linux (64 bit). I have not tried compiling for other boards, or even other sketches. But at least for this one case, switching from version 2.18 to 2.23.2 did solve this problem.

Hopefully this helps?

[cmaglie]

From my tests I've seen that the problem arises when a very specific amount "N" of memory is allocated statically by the sketch. I don't know the exact number N, but if you try to allocate a bit more or a bit less (by removing or adding a variable for example) this makes the linker happy.

Paul the bugzilla report that the issue was found on 2.24, I fear that 2.23.2 still has the problem but you just can't trigger it with the same sketch used on 2.18.

C

[PaulStoffregen]

I looked at the source for binutils 2.23.2. It definitely does have the patch from issue 13410.

[abcd-ca]

I am having the same problem with Arduino 1.0.5, Arduino Mega 2650. Program bytes where I have trouble adding additional F() statements (due to being JUST at the limit) : 65,674. When I remove all the F() calls my program is reduced to 49,076, FYI. As you probably know, Arduino reports that the Mega's Flash limit should actually be 258,048.

[abcd-ca]

I think I might have a fix. I'm able to get my program up to over 100K (I added a bunch of Serial.println(F("foo")) text to push it over the limit).

In the Arduino IDE 1.0.5 source code, I removed the --relax param in Compiler.java and then as a result, apparently in Print.h needed change DEC, HEX, OCT and BIN from defines to const uint8_t's.

See my comment on this thread, http://forum.arduino.cc/index.php?topic=140108.msg1646133#msg1646133

[cmaglie]

The following nightly builds contains an updated toolchain that should solve the problem (#1903):

http://downloads.arduino.cc/arduino-avr-toolchain-nightly-gcc-4.8.1-linux32.tgz http://downloads.arduino.cc/arduino-avr-toolchain-nightly-gcc-4.8.1-linux64.tgz http://downloads.arduino.cc/arduino-avr-toolchain-nightly-gcc-4.8.1-macosx.zip http://downloads.arduino.cc/arduino-avr-toolchain-nightly-gcc-4.8.1-windows.zip

[cmaglie]

The new gcc has been released with Arduino IDE 1.5.7

[mickys]

Issue still presents itself when using Attiny chips as mentioned at http://forum.arduino.cc/index.php?topic=116674.30

Tested on Arduino IDE 1.0.6 on a mac code compiles fine for 168 / 328 or Mega boards, but breaks as seen in the bug report for attiny85.