[Top][All Lists]

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

Re: [avr-gcc-list] ATMega 2560 + RAMPZ + 128Kplus and the realproblem on

From: Jan Waclawek
Subject: Re: [avr-gcc-list] ATMega 2560 + RAMPZ + 128Kplus and the realproblem on GCC
Date: Sun, 7 Apr 2013 01:20:31 +0200

> > >Starting with gcc 4.7.x, code
> > >beyond 128 KB works right away provided you link with relaxation turned
> > >on
> > 
> > Why would relaxation needed to be turned on?
> > 
> That was because of PR 14058, which, I just realized, is already fixed

Ah, so.

I put up this question already twice, once on avrfreaks.net, once here, and 
never received any answer, not even from Georg-Johann who put that remark into 
the official gcc documentation; so I am assuming that at least he is still 
uncertain that that was the only issue and that the fix solved it. 

I always deliberately avoided the situations which would result in trampolines 
in my ATMega256x project (and am still using a 2007-vintage WinAVR as my main 
tool), so, as a matter of fact, I don't have personal experience with this 

Also, purely technically, it's not the compiler version which is pertinent to 
the trampolines/stubs-related bugs fixes, as they were fixed in the linker 
(unless there were other related bug fixes in the compiler itself I am not 
aware of).

> So I guess relaxation in this case only serves to reduce the size of the
> trampoline table then, by not generating stubs for code that is
> reachable directly?

That is the intention at least (although, again purely technically, I would 
speak of the relaxation process removing the unneeded stubs after they have 
been created by the "regular" linking process).


reply via email to

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