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

[Jan Waclawek]

> > >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 
issue.

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).

JW