[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
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