[Bug ld/29741] AVR ld unable to link for 0-series MCUs
https://sourceware.org/bugzilla/show_bug.cgi?id=29741 Nick Clifton changed: What|Removed |Added Last reconfirmed||2022-11-02 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Konrad, Are you able to test out a patch and see if it solves the problem for you ? If so, please try the patch that I am about to upload. It implements your idea, allowing the user to define __DATA_REGION_ORIGIN__ on the linker command line, overriding the built-in default value. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29741] AVR ld unable to link for 0-series MCUs
https://sourceware.org/bugzilla/show_bug.cgi?id=29741 --- Comment #2 from Nick Clifton --- Created attachment 14430 --> https://sourceware.org/bugzilla/attachment.cgi?id=14430&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29737] strip: section attributes to indicate strip or persistent sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29737 --- Comment #5 from Nick Clifton --- (In reply to Guillermo E. Martinez from comment #4) Hi Guillermo, > > Are you asking for strip to be able to keep or remove sections based upon > > their attributes, rather than their names ? > > Exactly. This bugzilla is to provide the feedback and support triggered by > the discussion for standardize a way to indicates whether sections should be > preserved or not after binutils strip/eu-strip execution without need to use > special arguments, OK, so lets assume that we restrict this to ELF format files only. Basically the idea is, (I think...), we define a new section flag, eg: SHF_GNU_CAN_BE_STRIPPED which would be set by the linker on any section that it believes is not necessary for proper execution of the binary. (ie debug info sections, notes that are not needed by the loader, etc). In addition tools like objcopy should be able to add or remove this flag from specific sections at the behest of the user. The purpose of the flag is to tell tools like strip and eu-strip that the section can and should be removed or preserved when stripping or creating a debuginfo file. (At the moment this decision is made by heuristics built into these tools, and the heuristics differ...) In order to support backwards compatibility with files that do not use this scheme, it will probably also be necessary to define a second flag: SHF_GNU_DO_NOT_STRIP Then the tools can detect sections which have not been annotated with this new feature and fall back on their old heuristics instead. - Does that sound about right ? If so then I think that the proper way to proceed with this idea is to present it on the GNU gABI list (gnu-g...@sourceware.org) rather than discussing it inside a binutils PR. Do you agree ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
https://sourceware.org/bugzilla/show_bug.cgi?id=25202 gökçe changed: What|Removed |Added CC||sourceware.org at aydos dot de --- Comment #4 from gökçe --- I had the same problem like Olof while copying a little-riscv32 a verilog target: ``` $ riscv64-elf-objcopy my.elf -O verilog --verilog-data-width=4 my.hex $ head -2 my.hex @8000 B7C0EDFE 9380D0EA 37E176FF 130161F5 ``` I used a oneliner as a workaround: ``` sed -E 's/([^@].)(..)(..)(..)([ $])/\4\3\2\1\5/g' my.hex > my-le.hex ``` > Seeing that bfd_targets are constants and passing the input bfd's endianness > to the verilog handler would be a huge code change for what only a single > format needs, would the best way to fix this be to create 2 verilog bfd > formats? ... I do not have any experience of binutils source code, but I read in the manual: > If the input format has an endianness (some formats do not), objcopy can only > copy the inputs into file formats that have the same endianness So if the output format cannot dynamically change endianness, then Alex's proposal makes sense. Is someone working on this? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29739] [2.40 Regression] three regressions compared to 2.39 on arm-linux-gnueabihf
https://sourceware.org/bugzilla/show_bug.cgi?id=29739 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Confirmed. I bisected this to: commit 8cb6e17571f3fb66ccd4fa19f881602542cd06fc Author: Andrew Burgess Date: Fri Sep 2 18:15:30 2022 +0100 opcodes/arm: use '@' consistently for the comment character -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29739] [2.40 Regression] three regressions compared to 2.39 on arm-linux-gnueabihf
https://sourceware.org/bugzilla/show_bug.cgi?id=29739 Christophe Lyon changed: What|Removed |Added CC||aburgess at redhat dot com --- Comment #2 from Christophe Lyon --- Andrew, can you have a look? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29739] [2.40 Regression] three regressions compared to 2.39 on arm-linux-gnueabihf
https://sourceware.org/bugzilla/show_bug.cgi?id=29739 Christophe Lyon changed: What|Removed |Added Assignee|unassigned at sourceware dot org |clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- Actually the fix is simple, I'll send a (testsuite-only) patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29739] [2.40 Regression] three regressions compared to 2.39 on arm-linux-gnueabihf
https://sourceware.org/bugzilla/show_bug.cgi?id=29739 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Christophe Lyon --- Fixed by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7eb96b2f0359aa8cc1134fc6af4865f59e71d884 (git commit 7eb96b2f0359aa8cc1134fc6af4865f59e71d884) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29739] [2.40 Regression] three regressions compared to 2.39 on arm-linux-gnueabihf
https://sourceware.org/bugzilla/show_bug.cgi?id=29739 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Christophe Lyon : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7eb96b2f0359aa8cc1134fc6af4865f59e71d884 commit 7eb96b2f0359aa8cc1134fc6af4865f59e71d884 Author: Christophe Lyon Date: Wed Nov 2 16:50:15 2022 + arm: PR 29739 Fix typo where ';' should not have been replaced with '@' ';' does not always indicate the start of a comment, and commit 8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3 instances of ';' with '@' in expected diagnostics, leading to tests failures. This patch restores the original ';' as needed in these testcases. Fixes bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29739 -- You are receiving this mail because: You are on the CC list for the bug.
Issue 52668 in oss-fuzz: binutils:fuzz_objdump: Unexpected-exit in xexit
Updates: Labels: -restrict-view-commit Comment #3 on issue 52668 by sheriffbot: binutils:fuzz_objdump: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52668#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/29741] AVR ld unable to link for 0-series MCUs
https://sourceware.org/bugzilla/show_bug.cgi?id=29741 --- Comment #3 from Konrad Rosenbaum --- The patch worked. I applied it to vanilla binutils 2.39 (git: b51c2fec1da2) and recompiled binutils and GCC (12.2.0). The combination is able to compile and link. And the resulting binary works on the actual MCU (tested with AtMega1608, which is the most troublesome one I had handy). Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
