avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] avr-ld: Do linker stubs need --relax?


From: Bjoern Haase
Subject: Re: [avr-gcc-list] avr-ld: Do linker stubs need --relax?
Date: Mon, 07 May 2012 16:23:32 +0200
User-agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0

Hello Joerg,

The question "Is using linker stubs supported without --relax at
all?" came up recently, namely in

I don't recall all the details. Generally, linker stubs are supposed to be functional without relaxing. However, when reading the comments, there seems to be a bug that is related to code that removes unused stubs, which actually requires the use of the --relax switch.

Yours,

Bjoern.


Am 04.05.2012 20:20, schrieb Joerg Wunsch:
Georg-Johann Lay<address@hidden>  wrote:

The question "Is using linker stubs supported without --relax at
all?" came up recently, namely in
http://sourceware.org/PR14058#c4
AFAIR correct handling/generation of stubs needs --relax, but I
cannot find it documented in binutils nor together with -mrelax
documentation in avr-gcc.
This is how I understood Björn Haase when he implemented all this many
years ago (and thus brought us an AVR GNU toolchain usable for devices
with more than 128 KiB of flash).  I don't know enough of the linker
stub internals to judge whether his implementation is buggy or not.
If Jan's assertion (that they are buggy because of this requirement)
are correct, this would imply there were a way to resolve the bug
without requiring linker relaxations.

It's my understanding that architectures using linker stubs aren't
that common in GNU binutils (IIRC Björn referred to some Hitachi
implementation as an example that already existed before), so it would
not be surprising to see that there is missing documentation about
certain things around it.

HI'm trying to Cc Björn, in case he might want to state a more founded
opinion on this than mine is.




reply via email to

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