[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?

From: Jim Brain
Subject: Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?
Date: Thu, 03 May 2012 11:50:05 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 5/3/2012 1:28 AM, Jan Waclawek wrote:
As the first step, I'd recommend you to use a proven toolchain, like 
I am using just that toolchain. I will, though, download the below linked toolchain as well.
with potentially other yet unknown problems. If you'd insist on that, I'd recommend you 
to pick Georg-Johann's build from 
 , discussed in 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=115337 .
I will grab that one as well. I like that the one I earlier downloaded is libc 1.8, but maybe that's too bleeding edge :-)

On 5/3/2012 1:52 AM, Joerg Wunsch wrote:
*which* relocations are truncated?
It moved around, depending on how much code I compiled in. The last batch were EEPROM routine references. I refrained from sending to the list since I didn't want to force people to eval the issue, I just thought there was a reference work I would follow.

What are your compiler commandline options?  I hope you didn't use the
silly -mshort-calls option.  This option would better not exist at
*hangs head in shame* Yes, I did. After removal, compilation is back to normal. And, the other code I references was lacking that flag, which is no doubt why it worked.

In my (somewhat lame) defense, I believe I copied this Makefile from a Tiny2313 project (it started life on a Tiny), and was trying to keep code size at a bare minimum.

On 5/3/2012 2:34 AM, Erik Christiansen wrote:
There are various ways to achieve an error making that reference. (Did it also report "relocation truncated to fit:"? Last time I did it, the cause was an rjmp where an ljmp was needed.) [...]
It did. It was late when I wrote the email, and my head was hurting from all of the tests I tried.
Having neither complete error messages nor code, we are powerless to offer specific advice. However, if it is a linking issue, then comparing the address of the failing instruction and the address of the destination, and examining the generated assembler code, should help clarify whether you just need to change the code to better reach the destination, or the compiler is letting you down, or ...
The missing full error message is my fault. I didn't immediately share the code because I didn't want to burden people on the list with doing the diagnosis. Well, that and I am in the process of going through all of my AVR C and rewriting the functions to better reflect C best practices. Translation: not done yet, still abusing macros and conditional code compilation, and would rather not be completely laughed off the list.

Hopefully, this list is searchable by Google, and the next poor sap that finds this issue can check to see if he/she has short-calls on the flag list, and thus my message will have helped someone avert hours of frustration.

Now, I need to find a "So, you're moving to avr-libc 1.8, here's things you'll have to change" primer, as

o I've already had to add "inline" to some functions that were marked as "static void ps2_host_timer_irq(void) __attribute__((always_inline))", which seemed strange to me o I am using void uart0_puts_P(prog_char *text) { and I think that has to change to :void uart0_puts_P(const char *text) {

In the GCC arena, I'm off to research flags, as:

o Looks like --param inline-call-cost=3 is no more, and I wonder if GCC is now a bit less agressive at inlining (4.3.3 was very aggressive)

I do appreciate the help, and I'm glad it was a simple issue, no bug report, etc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]