$ cat crash.s main: nop rjmp main ret rjmp main $ avr-gcc -mmcu=atmega8 -Wl,--relax crash.s collect2: ld terminated with signal 11 [Segmentation fault], core dumped
This came up in some actual code and I condensed it to the minimal example above. The nop can be any instruction. The two references to main seem necessary, and the ret is key. I'm thinking that the linker must be examining the instructions to find routines or something. Apologies if this has already been reported.
Which version?
You could also play with the relax/stubs/whatever-related options; run (avr-)ld with --help as they seem to be undocumented in the ld documentation.
JW
PS. http://sourceware.org/bugzilla/s... came into mind
Which version?
uid23021@ws-czc1138h0b:~$ avr-gcc -mmcu=atmega8 -Wl,--relax crash.s collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped uid23021@ws-czc1138h0b:~$ avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/avr/bin/../libexec/gcc/avr/4.7.2/lto-wrapper Target: avr Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/src/gcc/configure LDFLAGS=-L/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib CPPFLAGS= --target=avr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --libdir=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-mpfr=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.4.2_939 --with-bugurl=http://www.atmel.com Thread model: single gcc version 4.7.2 (AVR_8_bit_GNU_Toolchain_3.4.2_939)
Something similar using their Windows build of 4.7.2 too..
And here just a couple months ago we told John to relax; just relax"... ;)
https://www.avrfreaks.net/index.p...
This is a linker bug, and most probably an already unreported one. Please report it in the binutils tracker.
---
The linker relaxation is complex, and prone to errors, as proven several times in past. And there are also built-in bombs, like:
/* Shrinking the code size makes the gaps larger in the case of wrap-arounds. So we use a heuristical safety margin to avoid that during relax the distance gets again too large for the short jumps. Let's assume a typical code-size reduction due to relax for a 16k device of 600 bytes. So let's use twice the typical value as safety margin. */
JW
Ahhh, so it's trying to follow jumps and change the code, and gets stuck in a loop or something. Cute.
I'm not clear on where I'd report the bug. I'm running Ubuntu 12.04 LTS. The reportbug program apparently isn't supported (*** ERROR: "Ubuntu" BTS is currently unsupported. Please use "ubuntu-bug"
(from the apport package) for reporting bugs in Ubuntu. [...]) and it's not clear that Debian wants a bug report from a different distribution or that my report would go to the right people. If you can direct me to a place you're sure it can be reported, I'll do it there.
No. The error is in the linker, which is part of the binutils project, so that's where it ought to be reported.
But I took the liberty to post it there, together with some additional comments.
https://sourceware.org/bugzilla/...
JW
That gives more insight for me into it. It came up in an instruction tester where each instruction to be tested was in a list with "rjmp done" was between each one. So I had a pointer I was stepping through, which the linker couldn't know about. So I know to not use --relax for any unconventional asm code like this. It's just an optimization.
