[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] .trampolines location. Was: Current patch queue again
From: |
Georg-Johann Lay |
Subject: |
Re: [avr-gcc-list] .trampolines location. Was: Current patch queue against binutils upstream |
Date: |
Mon, 10 Dec 2012 23:33:37 +0100 |
User-agent: |
Thunderbird 2.0.0.24 (Windows/20100228) |
Jan Waclawek schrieb:
Georg-Johann Lay wrote:
* PR13812 .trampolines location in linker script cause "internal
error: out of range error"
Dunno if this is still an issue resp. can be solved by a better
default linker script. Maybe a user-specific ld script is needed
here, too.
I'd say, this is not a bug, but abuse of the .progmem(.data) section,
Not really. Problems arise if .trampolines is shifted out of the first
128KiB segment if .progmem gets too big. Notice that .trampolines is
located *after* .progmem, thus a fix is to locate .trampolines before
.progmem.
to be resolved by enhanced documentation and adding dedicated "high
progmem" section(s) into the linker script. I "asked" for such in
https://savannah.nongnu.org/bugs/?26365 , I am unable to resolve the
AFAIK see that is related to non-volatile data in flash, not to linker
stubs?
details myself. Some diagnostic/warning issued by linker would be
nice but is not worth the hassle, IMHO.
I wonder how the linker can know? In order to tell anything about this,
it would need more information, e.g. specific section flags or similar.
Currently there is no means to tell the linker: How could the linker
tell if you wrote PSTR or PSTRX or whatever?
Basically #26365 addresses similar issues like PR14406 with the
difference that the compiler already supports everything needed for data
in __flash1 or higher, as avr-gcc calls is.
The trouble with that approach is that I found no way to express
different flash usage scenarios in one linker script, e.g. you want to
use segment #1 (2nd 64 KiB chunk) [A] for program or [b] for data.
Data for __flash1 will be put into input section .progmem1.data, but I
found no way to describe that in the linker script.
Likely it's only because my very rudimentary ld-script skills.
[...] I won't comment in the binutils tracker, as this is a highly
personal view and I believe many will find it controversial.
Sorry? I don't understand what you write.
Johann
- [avr-gcc-list] Current patch queue against binutils upstream, Bastien ROUCARIES, 2012/12/10
- Re: [avr-gcc-list] Current patch queue against binutils upstream, Georg-Johann Lay, 2012/12/10
- Re: [avr-gcc-list] Current patch queue against binutils upstream, Jan Waclawek, 2012/12/10
- Re: [avr-gcc-list] .trampolines location. Was: Current patch queue against binutils upstream,
Georg-Johann Lay <=
- Re: [avr-gcc-list] .trampolines location. Was: Current patch queue against binutils upstream, Jan Waclawek, 2012/12/10
- [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Erik Christiansen, 2012/12/11
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Georg-Johann Lay, 2012/12/11
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Erik Christiansen, 2012/12/12
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Erik Christiansen, 2012/12/13
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Georg-Johann Lay, 2012/12/13
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.], Georg-Johann Lay, 2012/12/13
- [avr-gcc-list] Linker script patch to handle __flashN [Was: Handling __flash1 and .trampolines], Erik Christiansen, 2012/12/13
- Re: [avr-gcc-list] Linker script patch to handle __flashN [Was: Handling __flash1 and .trampolines], Georg-Johann Lay, 2012/12/13
- Re: [avr-gcc-list] Linker script patch to handle __flashN, Erik Christiansen, 2012/12/15