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

[Jim Brain]

On 5/3/2012 1:28 AM, Jan Waclawek wrote:
> As the first step, I'd recommend you to use a proven toolchain, like 
> WinAVR20100110.
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 
> http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
>  , 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
> all.
*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.

Jim