[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #15 from Senthil Kumar Selvaraj --- FWIW, the linker behavior is now fixed - https://sourceware.org/bugzilla/show_bug.cgi?id=20302
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #14 from Senthil Kumar Selvaraj --- Filed https://sourceware.org/bugzilla/show_bug.cgi?id=20302 to have the linker treat -T like all other options - i.e. consider the last occurrence of an option rather than the first one.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
--- Comment #13 from Georg-Johann Lay ---
(In reply to Senthil Kumar Selvaraj from comment #12)
> This works if the start of data is specified as -Tdata 0xaddress. Other ways
> of specifying the same thing don't work; -Tdata=0xaddress,
> -Wl,-Tdata=0xaddress or -Wl,-Tdata,0xaddress all fail.
Hard to fix all these in the compiler like -Wl,--section-start
We could document the current behavior and that -Tdata or -Ttext should be
used.
Or we could introduce a new option to use in the specs only and that also wraps
around like %{!mnew-option:%{!Tdata:Tdata ...}}
In any case the user must read the documentation and be aware of the new option
or the recommended practice.
A new option does not make much sense because instead of -mnew-option she could
just as well use -Tdata as needed...
> Do you know why the linker picks the option first appearing on the
> commandline, rather than the usual last?
No, and dunno how the linker handles several maybe conflicting multiple
specifications.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 Senthil Kumar Selvaraj changed: What|Removed |Added CC||saaadhu at gcc dot gnu.org --- Comment #12 from Senthil Kumar Selvaraj --- This works if the start of data is specified as -Tdata 0xaddress. Other ways of specifying the same thing don't work; -Tdata=0xaddress, -Wl,-Tdata=0xaddress or -Wl,-Tdata,0xaddress all fail. Do you know why the linker picks the option first appearing on the commandline, rather than the usual last?
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED Host|x86_64-linux-gnu| Resolution|--- |FIXED Target Milestone|--- |6.2 Build|x86_64-linux-gnu| Severity|minor |enhancement --- Comment #11 from Georg-Johann Lay --- Fixed in 4.9.4, 5.5 and 6.2+.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
--- Comment #10 from Georg-Johann Lay ---
Author: gjl
Date: Tue Jun 21 11:00:54 2016
New Revision: 237643
URL: https://gcc.gnu.org/viewcvs?rev=237643=gcc=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/driver-avr.c (avr_device_to_data_start):
Wrap -Tdata into %{!Tdata:...}.
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/avr/driver-avr.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
--- Comment #9 from Georg-Johann Lay ---
Author: gjl
Date: Tue Jun 21 10:43:12 2016
New Revision: 237641
URL: https://gcc.gnu.org/viewcvs?rev=237641=gcc=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
--- Comment #8 from Georg-Johann Lay ---
Author: gjl
Date: Tue Jun 21 10:39:59 2016
New Revision: 237640
URL: https://gcc.gnu.org/viewcvs?rev=237640=gcc=rev
Log:
Backport from 2016-06-21 trunk r237639.
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
--- Comment #7 from Georg-Johann Lay ---
Author: gjl
Date: Tue Jun 21 10:36:13 2016
New Revision: 237639
URL: https://gcc.gnu.org/viewcvs?rev=237639=gcc=rev
Log:
PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #6 from Georg-Johann Lay --- As of GCC 5 this should be no issue any more: The new device specs might specify -Tdata e.g. specs-atmega88 reads *link_data_start: -Tdata 0x800100 The file is located in $prefix/lib/gcc/avr/$version/device-specs/ provided default paths are used with configure. Cf. also the relevant release notes. Hence you could -- Drop that -Tdata from the device specs and specify appropriate -Tdata on the command line. -- Provide custom specs file derived from the one above. Sounds strange that bootloader and application are managed that way. Ususally, after the bootloader has finished, its memory is no more needed and will be cleaned up by the application's start-up code and used by the application without any conflicts.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
Andreas Fritiofson e9fritte at etek dot chalmers.se changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Known to work|4.2.0 |
Host|i486-linux-gnu |x86_64-linux-gnu
Version|4.1.0 |4.8.2
Resolution|WORKSFORME |---
Build|i486-linux-gnu |x86_64-linux-gnu
Severity|normal |minor
--- Comment #5 from Andreas Fritiofson e9fritte at etek dot chalmers.se ---
Just updating this to note that this still/again fails, however not exactly the
same as in my original report.
Using --section-data=.data=0x800200 correctly overrides the -Tdata 0x800100
that gcc adds for some AVRs.
But the (according to ld docs) equivalent -Tdata=0x800200 is silently discarded
and the .data section remains at 0x800100, causing havoc at runtime.
Can't tell if this is a bug in binutils or if this is intended behavior and gcc
should adapt the collect2 arguments to avoid triggering it.
Minimal test cases:
$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.8.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib
--enable-long-long --enable-nls --without-included-gettext --disable-libssp
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.8.2 (GCC)
$ avr-ld -v
GNU ld (GNU Binutils) 2.23.1
$ echo 'int main(void) { return 0; }' main.c
Works:
$ avr-gcc -mmcu=atmega88 -Wl,-Map,main.map,--section-start,.data=0x800200 -o
main.elf main.c grep ^.data main.map
.data 0x008002000x0 load address 0x005c
Fails:
$ avr-gcc -mmcu=atmega88 -Wl,-Map,main.map,-Tdata=0x800200 -o main.elf main.c
grep ^.data main.map
.data 0x008001000x0 load address 0x005c
Works:
$ avr-gcc -mmcu=atmega8 -Wl,-Map,main.map,-Tdata=0x800200 -o main.elf main.c
grep ^.data main.map
.data 0x008002000x0 load address 0x004e
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #3 from e9fritte at etek dot chalmers dot se 2007-06-28 19:29 --- At that time I was probably using binutils 2.16 (Ubunty Edgy). It seems Feisty still has that version. It's great if this has been resolved in 4.2, although my workaround does its job for now. Thanks to whoever fixed it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #4 from eweddington at cso dot atmel dot com 2007-06-28 19:48 --- Closing bug as WORKSFORME. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #2 from eweddington at cso dot atmel dot com 2007-06-23 15:39 --- Works for me with gcc 4.2.0 and binutils 2.17. Andreas, what version of binutils are you using? -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #1 from e9fritte at etek dot chalmers dot se 2007-01-09 22:09 --- Adding me to CC list. -- e9fritte at etek dot chalmers dot se changed: What|Removed |Added CC||e9fritte at etek dot ||chalmers dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
