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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
