[Bug ld/24564] [avr] Link fails for rjmp/rcall to symbols at range boundary with pmem-wrap-around
https://sourceware.org/bugzilla/show_bug.cgi?id=24564 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Senthil Kumar Selvaraj : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=338ba75534fbfeb64d7009f29a89f25826a1f4d2 commit 338ba75534fbfeb64d7009f29a89f25826a1f4d2 Author: Senthil Kumar Selvaraj Date: Thu May 16 17:16:36 2019 +0530 Fix PR 24564 - link fails for some rcalls/rjmps with wraparound The current code to compute relative distance in the wrap around case does not handle the edge case of the target (after adjusting for implicit PC increment) being exactly half of the wrap around distance. This patch fixes that and adds a testcase. The range for a forward relative jump call is 4096 bytes ((2 * 2047) + (2 bytes for the implicit PC increment)). If the target of the jump is at a distance of 4098 bytes, it is out of range for a forward jump - however, a backward jump can still reach that address if pmem-wrap-around is 8192. Assume address 0 has rjmp to address 4098. With a wrap around of 8192 and *without* adjusting for the implicit PC increment of 2 bytes, rjmp .-4096 will jump to address 4096 (wrap around at 8192 and decreasing addresses from then on). Adjusting 2 bytes for the implicit PC increment, the actual target is 4098. avr_relative_distance_considering_wrap_around though, does the wrap around only if the passed in distance is less than half of the wrap around distance. In this case, it is exactly equal to half (original distance 4098, adjusted distance of 4096 and wraparound of 8192), and the bypassed wrap around causes the reloc overflow error. Fix by wrapping around even if adjusted distance is equal to half of wrap around distance. -- 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/24571] [avr] Relaxation does not shorten jmp or call to target at pc-relative range boundary
https://sourceware.org/bugzilla/show_bug.cgi?id=24571 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Senthil Kumar Selvaraj : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7622049e0bef81fab900860400838bc977449892 commit 7622049e0bef81fab900860400838bc977449892 Author: Senthil Kumar Selvaraj Date: Thu May 16 12:12:33 2019 +0530 Fix PR 24571 - Relaxation does not shorten jmp or call to target at pc-relative range boundary The range check done to transform an absolute call/jump to a pc-relative one is off-by-one, and that causes this shortening optimization to be missed if the branch target is right at the range boundary. In the non-shrinkable case, the range is what is mentioned in the ISA - -4094 bytes in the backward direction, and 4096 bytes in the positive direction. In the shrinkable case, the forward jump range increases by two bytes (deleted because of the shortening from call/jmp to rcall/rjmp), and therefore, the range is -4094 in the reverse, and 4098 in the positive direction. Fix the ranges for !shrinkable and shrinkable cases, and add a test caes to ensure jumps to max forward and backward ranges get relaxed to rjmp. -- 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/24571] [avr] Relaxation does not shorten jmp or call to target at pc-relative range boundary
https://sourceware.org/bugzilla/show_bug.cgi?id=24571 Senthil Kumar Selvaraj changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Senthil Kumar Selvaraj --- Fixed with https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7622049e0bef81fab900860400838bc977449892 -- 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/24564] [avr] Link fails for rjmp/rcall to symbols at range boundary with pmem-wrap-around
https://sourceware.org/bugzilla/show_bug.cgi?id=24564 Senthil Kumar Selvaraj changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Senthil Kumar Selvaraj --- Fixed with https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=338ba75534fbfeb64d7009f29a89f25826a1f4d2 -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tamar Christina : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=739b5c9c778dee9e2f54d864f83a81ecb0639535 commit 739b5c9c778dee9e2f54d864f83a81ecb0639535 Author: Tamar Christina Date: Tue May 21 13:04:08 2019 +0100 AArch64: Implement choice between Cortex-A53 erratum workarounds. (PR ld/24373) The Cortex-A53 erratum currently has two ways it can resolve the erratum when using the flag --fix-cortex-a53-843419: 1) If the address is within the range of an ADR instruction it rewrites the ADRP into an ADR, and those doesn't need the use of a veneer. 2) If the address is not within range, it adds a branch to a veneer which will execute the final bit of the erratum workaround and branch back to the call site. When we do this we always generate the veneers and we always align the size of the text section to 4KB. This is because we only know which workaround we can use after all linking has finished and all addresses are known. This means even though the veneers are not used, we still generate the section and we still change the size of the input section. This is problematic for small memory devices as this would require the user to take about a ~4KB hit in memory even though it's not even used. Since there's no real way to restart the linking process from the final write phase this patch solves the issue by allowing the user more control over which erratum workaround gets used. Concretely this changes the option --fix-cortex-a53-843419 to take optional arguments --fix-cortex-a53-843419[=full|adr|adrp] - full (default): Use both ADRP and ADR workaround. This is equivalent to not specifying any options and is the default behavior before this patch. - adr: Only use the ADR workaround, this will not cause any increase in binary size but linking will fail if the referenced address is out of range of an ADR instruction. - adrp: Use only the ADRP workaround, this will never rewrite your ADRP. In the cases where the user knows how big their binaries are the `adr` option would prevent the unneeded overhead. bfd/ChangeLog: PR ld/24373 * bfd-in.h (enum erratum_84319_opts): New (bfd_elf64_aarch64_set_options, bfd_elf32_aarch64_set_options): Change int to enum erratum_84319_opts. * bfd-in2.h: Regenerate. * elfnn-aarch64.c (struct elf_aarch64_link_hash_table): Change fix_erratum_843419 to use new enum, remove fix_erratum_843419_adr. (_bfd_aarch64_add_stub_entry_after): Conditionally create erratum stub. (aarch64_size_one_stub): Conditionally size erratum 843419 stubs. (_bfd_aarch64_resize_stubs): Amend comment. (elfNN_aarch64_size_stubs): Don't generate stubs when no workaround requested. (bfd_elfNN_aarch64_set_options): Use new fix_erratum_843419 enum. (_bfd_aarch64_erratum_843419_branch_to_stub): Implement selection of erratum workaround. (clear_erratum_843419_entry): Update erratum conditional. ld/ChangeLog: PR ld/24373 * emultempl/aarch64elf.em (PARSE_AND_LIST_LONGOPTS): Add optional args to flags. * NEWS: Add changes to flag. (PARSE_AND_LIST_OPTIONS): Update help descriptions. (PARSE_AND_LIST_ARGS_CASES): Add new options to parser. * testsuite/ld-aarch64/aarch64-elf.exp: Add new run_dump_tests. * testsuite/ld-aarch64/erratum843419-adr.d: New test. * testsuite/ld-aarch64/erratum843419-adrp.d: New test. * testsuite/ld-aarch64/erratum843419-far-adr.d: New test. * testsuite/ld-aarch64/erratum843419-far-full.d: New test. * testsuite/ld-aarch64/erratum843419-far.s: New test. * testsuite/ld-aarch64/erratum843419-full.d: New test. * testsuite/ld-aarch64/erratum843419-near.s: New test. * testsuite/ld-aarch64/erratum843419-no-args.d: New test. -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 --- Comment #5 from Tamar Christina --- Hi Julius, Sorry for the delay, I couldn't find a reasonably feasible way to restart the linking, so instead I implemented a way to allow users to pick which workaround to use. In your case if you use `--fix-cortex-a53-843419=adr` it'll do what you want. If your application ends up being too big for this workaround linking will fail. Is this sufficient for your use case? -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 Tamar Christina changed: What|Removed |Added Target Milestone|--- |2.33 -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #6 from Christophe Lyon ---
Hi Tamar,
It seems your patch does not build on 32-bits hosts:
../../bfd/elfnn-aarch64.c: In function
‘_bfd_aarch64_erratum_843419_branch_to_stub’:
../../bfd/elfnn-aarch64.c:5312:2: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 3 has type ‘bfd_signed_vma’ [-Werror=format=]
(_("%pB: error: erratum 843419 immediate 0x%lx "
^
(on x86_32)
--
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 gas/24559] load pseudo-operation handling bug with Armv8-M Baseline
https://sourceware.org/bugzilla/show_bug.cgi?id=24559 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Andre Simoes Dias Vieira : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8fe9a076adf308ec813246a96f915c5ab5b6a75f commit 8fe9a076adf308ec813246a96f915c5ab5b6a75f Author: Andre Vieira Date: Tue May 21 14:51:43 2019 +0100 [GAS, Arm] PR24559: Fix pseudo load-operations for Armv8-M Baseline gas/ChangeLog: 2019-05-21 Andre Vieira PR 24559 * config/tc-arm.c (move_or_literal_pool): Set size_req to 0 for MOVW replacement. * testsuite/gas/arm/load-pseudo.s: New test input. * testsuite/gas/arm/m0-load-pseudo.d: New test. * testsuite/gas/arm/m23-load-pseudo.d: New test. * testsuite/gas/arm/m33-load-pseudo.d: New test. -- 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 binutils/24460] bfd/elf32-arm.c: get_value_helper, uninitialized value used
https://sourceware.org/bugzilla/show_bug.cgi?id=24460 Andre Vieira changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||avieira at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Andre Vieira --- I messed up the commit message for bfd/ChangeLog in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=e6f65e7573a317ac4efff26fe0e49fe1b9e7a596 But that commit fixes this issue, so closing as RESOLVED - FIXED. -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 --- Comment #7 from Tamar Christina --- Hmm interesting, didn't receive the error when building inside 32-bit schroot on AArch64 machine. I'll take a look, thanks! -- 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
Re: Bugs report for cplus-dem.c in GNU Binutils 2.31
Hi 乐泰, Thank you very much for reporting these bugs. Unfortunately there are a few problems with this report: * Bugs related to demangling in cplus-dem.c should actually be reported to the GCC project, not the BINUTILS project. This is because cplus-dem.c is part of the libiberty library, which is maintained as part of GCC. The binutils project makes use of the libiberty library, but it does not maintain it. * Bugs like this should be reported by using the appropriate bug reporting system. For GCC this is done by creating a new bug report here: https://gcc.gnu.org/bugzilla/show_bug.cgi (For future reference bug reports for the binutils project can be filed here): https://sourceware.org/bugzilla/ * You should try to use the latest version of the binutils sources when you run your tests. In this case the latest released version is 2.32 not 2.31. This is particularly important in this case because 2.32 contains several fixes to the cplus-dem.c source file. In fact when I tried to reproduce the failures you reported using the current development version of the binutils, none of them worked. Ie there were no segmentation faults of address violations detected. I hope that this information helps, and thank you once again for your interest in the binutils. Cheers Nick Clifton ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24557] Support underscore-prefixed string after mangled name (for CUDA PTX parameters)
https://sourceware.org/bugzilla/show_bug.cgi?id=24557 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |MOVED --- Comment #1 from Nick Clifton --- (In reply to Eyal Rozenberg from comment #0) Hi Eyal, > I would like c++filt to either auto-detect this case, or have an option to > detect it; I do not object to this request per-se, but there is a caveat: The demangling performed by c++filt is actually handled in a library (libiberty) which is part of the GCC project, not the binutils project. (The binutils project makes use of the library, but we do not maintain it). So you will need to refile this feature request with the GCC project. If they do decide to implement the feature, then there may also need to be some follow up work on c++filt itself. (Eg to pass a new flag into the demangling code in libiberty). If this happens I will be happy to add the necessary support to c++filt. It is possible however that the libiberty maintainers will not be terribly, umm, enthusiastic about adopting such a feature. In which case it may be possible to add a workaround to c++filt. For example a command line option to strip a suffix off the end of a mangled name. This does assume of course that there is a predictable suffix generated by the CUDA compiler. It also means that other tools that perform name demangling (eg gdb) would not be affected by the change, so they would still have the demangling problem. Please try asking the GCC folks first, but if that fails, please reopen this PR. Cheers Nick -- 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/24576] Feature request: error out when passed the same linker script with -T and as an object file
https://sourceware.org/bugzilla/show_bug.cgi?id=24576 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Julius Werner from comment #0) Hi Julius, > I don't think there could ever be a valid use case where you'd want to pass > the same file as an argument to -T and as an augment linker script later on, > so could you just add a check to error out somewhere if that happens? That > could save the people running into this a lot of headache. This seems like a reasonable request. Would you like to have a go at implementing the idea yourself and submitting a patch ? [A not so subtle attempt to get a new contributor interested in the binutils...] You could record the name of the last linker script parsed with the -T option by adding code to ld/lexsup.c:parse_args(), and then check it against the filenames that are processed by ld/ldfile.c:ldfile_try_open_bfd. If you are feeling particularly clever you could record *all* of the filenames used with -T as there could be multiple instances of it. Cheers Nick -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tamar Christina : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6467207116c66ff2c58f8bc35cb15b2596f5c457 commit 6467207116c66ff2c58f8bc35cb15b2596f5c457 Author: Tamar Christina Date: Tue May 21 17:15:36 2019 +0100 AArch64: Fix -Werror on build This patch fixes a hardcoded `l` specifier on a `bfd_signed_vma`. Instead this now uses BFD_VMA_FMT which fixes the build on 32 bit hosts. Committed under the obvious rule. bfd/ChangeLog: PR ld/24373 * elfnn-aarch64.c (_bfd_aarch64_erratum_843419_branch_to_stub): Fix print formatter. -- 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/24373] Arm Cortex-A53 Errata 843419 workaround inserts 4K stub even when unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=24373 --- Comment #9 from Julius Werner --- Hi Tamar, Thanks for taking care of this! I think it's a good solution that should be sufficient in practice. The kinds of binaries where an extra 4KB is a big deal should not be larger than 1MB anyway. For our use case, this should work just fine. -- 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 binutils/24557] Support underscore-prefixed string after mangled name (for CUDA PTX parameters)
https://sourceware.org/bugzilla/show_bug.cgi?id=24557 --- Comment #2 from Eyal Rozenberg --- (In reply to Nick Clifton from comment #1) > Please try asking the GCC folks first, but if that fails, please reopen this > PR. Have filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90566 for now. Thank you. -- 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/24576] Feature request: error out when passed the same linker script with -T and as an object file
https://sourceware.org/bugzilla/show_bug.cgi?id=24576 --- Comment #2 from Julius Werner --- Created attachment 11789 --> https://sourceware.org/bugzilla/attachment.cgi?id=11789&action=edit proposed fix Hi Nick, Okay, I looked into it and I think I found a reasonably clean way to do it (just checking that no linker script is ever parsed twice, because that just wouldn't make sense in any situation). However, I'm not quite sure how to submit my patch... I can't really find contributing guidelines for binutils anywhere. Can you link me to the right place or explain the process? (Attaching the patch here for lack of a better way to submit it.) -- 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
