[Bug ld/14058] Internal overflow error, on >128kB FLASH with no relaxation

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14058

--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-05-04 
13:42:39 UTC ---
(In reply to comment #6)

> The original bug report IMO contained everything needed to reproduce the bug
> and to assess it as different from the "trampolines high" case, without the
> need to read the avrfreaks.net thread.
>
> [...]
> 
> Moreover, I also believe that absolute placement of labels through .org
> (however deprecated it is for "real life" usage) is more illustrative of the
> underlying reason than your .space solution. Also the usage of --debug-stubs
> switch is not coincidental.

The reduced example from comment #4 removes external dependencies like

* avr-gcc
* crtmxxx.o from AVR-LibC
* Command options passed like -Tdata=

Please note that GCC and AVR-LibC are not part of binutils, so that I worked
out an example without these external dependencies.

Also note that /we/ want something from the binutils developers (I am not one
of them), in particular to fix problems. They do not want something from /us/.
It's us who need their help, knowledge, experience, time and pacience.

To help the developes fix a problem, we should not use external stuff, just as
an #include <avr/io.h> or #include "lcd.h" might deter a GCC developer from
tracking an avr-gcc issue. We should always strive to have no external
dependencies or references and self-contained and comprehensible reports.

For a binutils developer, the difference between two targets is just to switch
from --target=foo to --target=bar. Many stuff in binutils is /not/ AVR-related,
so we basically exclude all developers that would help with avr-binutils
problems that are not familiar with avr-gcc or want to install MS-windows
distributions or build AVR-Libc. I just stripped external stuff in order to
/not/ exclude any binutils developers.

As I played with the test case, I used .space just because I don't know the
semantics of .org; in particular you linked against crt so that the very code
startes after 0x100 and then there was an .org 0x100 in the code. So no drama
here.

Concerning the relatedness to PR13812 it might very well be the case that I am
plain wrong with my conclusions/"analysis" from there. It might be just as well
be the case that it's completely unrelated to "shifting stubs out of segment"
and instead is caused by "using gs() targeting different segments" as from this
PR.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.