[Bug ld/14058] Internal overflow error, on >128kB FLASH with no relaxation
http://sourceware.org/bugzilla/show_bug.cgi?id=14058 --- Comment #2 from Jan Waclawek 2012-05-03 20:45:27 UTC --- (In reply to comment #1) > If you use such big programs, .trampolines gets shifted out of it's 128KiB > section. No, they don't; I posted relevant portions of disassembly in the link given above. Adding to that, relevant portion of .map: .trampolines 0x00d00x4 linker stubs *(.trampolines*) 0x00d4__trampolines_end = . The key difference to the testcase in 13812 is that here .text is big, not .progmem. A quick look at the linker script reveals that .trampolines are above .progmem and below .text. Please re-read the original report and the post at the given link. -- 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
[Bug ld/14058] Internal overflow error, on >128kB FLASH with no relaxation
http://sourceware.org/bugzilla/show_bug.cgi?id=14058 --- Comment #5 from Jan Waclawek 2012-05-03 22:29:01 UTC --- > Is using linker stubs supported without --relax at all? While it is indeed possible to "administratively" suppress this bug by disallowing stubs without --relax, I believe this bug deserves to be fixed at some point as there may be "legal" reasons to avoid using --relax at times. This said, I understand that it may be a difficult task, so the vague error message could be replaced by a more descriptive one (perhaps also suggesting usage of --relax) as an interim solution. -- 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
[Bug ld/14058] Internal overflow error, on >128kB FLASH with no relaxation
http://sourceware.org/bugzilla/show_bug.cgi?id=14058 --- Comment #6 from Jan Waclawek 2012-05-03 22:37:12 UTC --- Hi Johann, I think what you wrote there is a bit unfair. 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. You shouldn't have edited out the "original post" from the quote in your response; that really changed the meaning of that sentence altogether. Also, do you really believe I would post a bug report without searching for existing duplicate bug report? I thought my work, however informally presented, doesn't indicate such approach. 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. In the avrfreaks.net thread, there is further information I inferred from reading the sources, which might be useful for those who would attempt to fix the bug. It may be incorrect, of course, as I did not have time to dig deep enough (read: I have to feed my family and as I said elsewhere already, I just tried to help others with their bugs and my code does not suffer from this bug due to my coding habits); that's why I did not push it futher. I believe those who are genuinely interested don't mind reading the post or whatever further information is available. Have a nice day (or night)! Jan - Original Message --- Subject: [Bug ld/14058] Internal overflow error, on >128kB FLASH with norelaxation From: "gjl at gcc dot gnu.org" Date: Thu, 03 May 2012 21:57:19 + To: konf...@efton.sk >http://sourceware.org/bugzilla/show_bug.cgi?id=14058 > >--- Comment #3 from Georg-Johann Lay 2012-05-03 >21:57:19 UTC --- >(In reply to comment #2) > >> Please re-read [...] the post at the given link. > >Please make bug reports that are self-contained. > >If there is information missing to reproduce the issue or to understand it, >please add the information to render the bug report self-contained. > >If the PR is already self-contained and includes all information, a link is >simply distracting and confusing and superfluous. > >Thanks. > >-- >Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email >--- You are receiving this mail because: --- >You reported the bug. -- 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
[Bug ld/14058] Internal overflow error, on >128kB FLASH with no relaxation
http://sourceware.org/bugzilla/show_bug.cgi?id=14058
Jan Waclawek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE |
--- Comment #8 from Jan Waclawek 2012-05-06 15:23:17
UTC ---
The bug is consequence of performing a relaxation-related optimisation step -
reduction of the stubs table (.trampolines section) through removing stubs
targeting labels which are directly reachable (i.e. are in the "segment"
pointed by the default EIND) when --relax has not been specified. This step is
performed in the elf32_avr_size_stubs() function in [binutils]/bfd/elf32-avr.c.
The stubs table is first created through calling elf32_avr_size_stubs() from
avr_elf_${EMULATION_NAME}_before_allocation() in
[binutils]/ld/emultempl/avrelf.em. It is called with the is_prealloc_run
parameter set to TRUE, which results in the complete table being built
containing all the targets of gs(). This step yields the maximal size of the
stubs table (.trampolines section), which is then used in the initial output
sections allocation.
When no relax, elf32_avr_size_stubs() is called second time from
avr_elf_after_allocation() (avrelf.em). The purpose of this is to fill the
stubs table with instructions for jumps to the target addresses, which thus
have to be known already (from the previous allocation). elf32_avr_size_stubs()
is called with is_prealloc_run parameter set to FALSE, but that results in
marking those stubs, which jump to "reachable" targets, as unused (note, that
this is the only purpose of the is_prealloc_run parameter, so its name is
misleading), thus the table's size might get reduced. As this results in moving
the target labels in the subsequent address fixing step of the linker, the stub
target addresses no longer match the real target addresses, which is then
detected in avr_final_link_relocate() at labels R_AVR_LO8_LDI_GS:,
R_AVR_HI8_LDI_GS: and R_AVR_16_PM: and the error is subsequently thrown.
(When --relax, the change of stubs section size is detected when calling
elf32_avr_size_stubs() from elf32_avr_relax_section() and if changed, through
setting *again invokes one more relaxation iteration which takes care of fixing
the changed target addresses).
The fix is surprisingly simple:
+++ avrelf.em Sun May 6 17:06:25 2012
@@ -152,7 +152,7 @@
{
/* If relaxing, elf32_avr_size_stubs will be called from
elf32_avr_relax_section. */
- if (!elf32_avr_size_stubs (link_info.output_bfd, &link_info, FALSE))
+ if (!elf32_avr_size_stubs (link_info.output_bfd, &link_info, TRUE))
einfo ("%X%P: can not size stub section: %E\n");
}
So now, elf32_avr_size_stubs() for the non-relax case won't drop any entry thus
the target addresses will remain correct.
It would be perhaps good also to rename the is_prealloc_run parameter of
elf32_avr_size_stubs() to something more appropriate, e.g. no_resize or such.
Please note, that while this fixes a genuine bug, it also removes a "beneficial
side effect" of the bug for those applications, which don't use --relax and at
the same time don't have gs() targets above 0x2 - so far they benefited
from complete removal of the unneeded stubs table (which went unnoticed as then
there were no incorrect stubs targets anymore). So, they now will experience
both growth in size (as the stubs table is not removed anymore) and decreased
execution speed (as indirect jumps will go through the stubs). As many of these
chips are in fact used for relatively small application and use the big flash
only for extensive data, this would impair a fair number of applications. In
spite of that, I don't think it's necessary to implement any other fix for this
other than change in documentation, which should recommend using the --no-stubs
switch for those cases.
--
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
[Bug ld/13899] [avr]: Wrong relaxation of R_AVR_16_PM with gs()
http://sourceware.org/bugzilla/show_bug.cgi?id=13899
Jan Waclawek changed:
What|Removed |Added
CC||konfera at efton dot sk
--- Comment #4 from Jan Waclawek 2012-05-09 07:59:38
UTC ---
During relax, if a call is shrunk to rcall, the relocs are modified accordingly
in elf32_avr_relax_delete_bytes(). This assumes that the relocs in case are
permanently kept in memory, which apparently ceased to be the case somewhere
between version 2.21 and 2.22 for reasons to me unknown. This has been noticed
also as http://sourceware.org/bugzilla/show_bug.cgi?id=13612, but "fix" for
http://sourceware.org/bugzilla/show_bug.cgi?id=12161 covered this up, by
loading the relocs, but they were not loaded permanently (keep-memory parameter
is FALSE).
Note that this did not occur with avr6 architecture, where stubs section is
created (unless --no-stubs is used); again I don't quite understand the
mechanisms behind this (sidenote: gs() is not appropriate for avr5
architecture).
The remedy is again surprisingly simple: _bfd_elf_link_read_relocs() has to be
called with keep-memory TRUE. (The below patch removes also the unneeded free()
and adds a couple of diagnostic printouts). While will probably increase memory
usage, in typical programs where multiple shrinks occur it should decrease the
linking time.
--- ../../elf32-avr.cMon May 7 05:27:50 2012
+++ elf32-avr.cWed May 9 09:12:47 2012
@@ -1513,7 +1513,11 @@
irel = elf_section_data (isec)->relocs;
/* PR 12161: Read in the relocs for this section if necessary. */
if (irel == NULL)
- irel = _bfd_elf_link_read_relocs (abfd, isec, NULL, NULL, FALSE);
+ {
+ irel = _bfd_elf_link_read_relocs (abfd, isec, NULL, NULL, TRUE);
+ if (debug_relax)
+ printf ("Relocs read in for %sec \n", isec->name);
+ }
for (irelend = irel + isec->reloc_count;
irel < irelend;
@@ -1573,8 +1577,6 @@
the addend. */
}
- if (elf_section_data (isec)->relocs == NULL)
- free (irelend - isec->reloc_count);
}
}
@@ -2276,6 +2278,8 @@
return TRUE;
error_return:
+ if (debug_relax)
+printf ("Something went wrong during relaxing...\n");
if (isymbuf != NULL
&& symtab_hdr->contents != (unsigned char *) isymbuf)
free (isymbuf);
--
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
[Bug ld/16005] New: [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 Bug ID: 16005 Summary: [avr] Linker crash on a particular instruction sequence with --relax Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: konfera at efton dot sk As reported in http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=136763 , the linker for avr target crashes when trying to relax a rjmp/ret sequence. The test case (crash.s): main: nop rjmp main ret rjmp main >avr-as crash.s -o crash.o >avr-ld --relax --debug-relax crash.o -o crash.elf Observations: 1. this occurs on various builds ranging back 5 years, hosted both on Win and Linux, although the visible symptoms vary, on some builds ld ends silently and generates an empty output file 2. the second rjmp is not needed, a nop or any other instruction would do. In fact, the observation is, that the error is not occuring if there is no instruction after the ret 3. the target of rjmp is irrelevant, it can be any symbol 4. adding --debug-relax switch reveals more details: the error occurs as the consequence of rjmp / ret detection and subsequent ret removal >avr-ld --relax --debug-relax crash.o -o crash.elf found rjmp / ret sequence at address 0x2 unreachable ret instruction at address 0x4 deleted. This locates the error into bfd/elf32-avr.c:elf32_avr_relax_delete_bytes(), being called just after the debug printout "unreachable ret instruction... deleted". 5. Replacing the first rjmp by jmp or rcall results in normal linking. This is interesting, because both the jmp/ret and rcall/ret sequences are in previous relaxation iteration replaced by rjmp/ret sequence, thus then undergo the same ret-removal procedure, which in this case is completed correctly: main: nop rcall main ret rjmp main >avr-as crash.s -o crash.o >avr-ld --relax --debug-relax crash.o -o crash.elf converted rcall/ret sequence at address 0x2 into rjmp/ret sequence. Section is . text found rjmp / ret sequence at address 0x2 unreachable ret instruction at address 0x4 deleted. Relocation at address 0x6 needs to be moved. Old section offset: 0x6, New section offset: 0x4 Checking if the relocation's addend needs corrections. Address of anchor symbol: 0x0 Address of relocation target: 0x0 Address of relaxed insn: 0x2 Checking if the relocation's addend needs corrections. Address of anchor symbol: 0x0 Address of relocation target: 0x0 Address of relaxed insn: 0x2 --- Stepping through elf32_avr_relax_delete_bytes() for the original input file results in crash in this line: memmove (contents + addr, contents + addr + count, (size_t) (toaddr - addr - count)); (which is conditionally executed only if there is anything to move, which btw. matches observation 2). contents was found to be NULL. As previously in this routine contents = elf_section_data (sec)->this_hdr.contents; it's elf_section_data (sec) which is not properly set up. Indeed, in the only other case when elf32_avr_relax_delete_bytes() is called (in the jmp/call shrink branch of the relaxation loop), there are several lines which might be relevant: /* Note that we've changed the relocs, section contents, etc. */ elf_section_data (sec)->relocs = internal_relocs; elf_section_data (sec)->this_hdr.contents = contents; symtab_hdr->contents = (unsigned char *) isymbuf; Copying these three lines just before the other call to elf32_avr_relax_delete_bytes() and recompiling the linker, appears to have fixed the problem. Unfortunately, I am not versed enough to judge, whether this is a proper fix to the problem. -- 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
[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 Jan Waclawek changed: What|Removed |Added CC||gjl at gcc dot gnu.org, ||konfera at efton dot sk -- 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
[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax
https://sourceware.org/bugzilla/show_bug.cgi?id=16005 Jan Waclawek changed: What|Removed |Added CC|gjl at gcc dot gnu.org |eric.weddington at atmel dot com -- 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
