[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The binutils-2_37-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0effb90eb7c9a50408d98ce174f1b4bc5562f017 commit 0effb90eb7c9a50408d98ce174f1b4bc5562f017 Author: Alan Modra Date: Wed Oct 20 10:09:57 2021 +1030 PR28417, std::string no longer allows accepting nullptr_t PR 28417 * incremental.cc (Sized_relobj_incr::do_section_name): Avoid std:string undefined behaviour. * options.h (Search_directory::Search_directory): Likewise. (cherry picked from commit 068a039b8bd7c7386bb0d88f0ae245b0fe4132e9) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27625] powerpc64: gold erroneously rejects linking code that calls __tls_get_addr
https://sourceware.org/bugzilla/show_bug.cgi?id=27625 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The binutils-2_37-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6bb799d2229595220090ae1f7eb2741b32d53051 commit 6bb799d2229595220090ae1f7eb2741b32d53051 Author: Alan Modra Date: Wed Oct 20 09:12:48 2021 +1030 Re: PR27625, powerpc64 gold __tls_get_addr calls My previous PR27625 patch had a problem or two. For one, the error "__tls_get_addr call lacks marker reloc" on processing some calls before hitting a call without markers typically isn't seen. Instead a gold assertion fails. Either way it would be a hard error, which triggers on a file contained in libphobos.a when running the gcc testsuite. A warning isn't even appropriate since the call involved is one built by hand without any of the arg setup relocations that might result in linker optimisation. So this patch reverts most of commit 0af4fcc25dd5, instead entirely ignoring the problem of mis-optimising old-style __tls_get_addr calls without marker relocs. We can't handle them gracefully without another pass over relocations before decisions are made about GOT entries in Scan::global or Scan::local. That seems too costly, just to link object files from 2009. What's more, there doesn't seem to be any way to allow the libphobos explicit __tls_get_addr call, but not old TLS sequences without marker relocs. Examining instructions before the __tls_get_addr call is out of the question: program flow might reach the call via a branch. Putting an R_PPC64_TLSGD marker with zero sym on the call might be a solution, but current linkers will then merrily optimise away the call! PR gold/27625 * powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_, and tls_opt_error_ variables and accessors. Remove all uses. (cherry picked from commit c7fdac09d919aaf86d302e6c622de6ee000c1b7c) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #21 from Tamar Christina --- (In reply to pjo...@redhat.com from comment #19) > Can you share your tree so we can replicate this locally? I have pushed it to a branch called `users/ARM/efi-aarch64-support-binutils` Would appreciate if you could help test it before I push it for review. With the branch objcopy will recognize `--target=efi-app-aarch64` as an efi app for aarch64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] New: ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 Bug ID: 28485 Summary: ar and objcopy stuck,failing on object name containing '/' inside an archive Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pullin at berkeley dot edu Target Milestone: --- I am trying to localize some symbols in objects inside an archive. Ultimately, it seems like the tools are failing because the .a appears to contain an object with the name "bin/thumbv7em-none-eabihf.o". This all started from trying: arm-none-eabi-objcopy --localize-hidden librustlib.a So operations like: arm-none-eabi-objcopy -L __aeabi_dcmpgt librustlib.a result in the error: arm-none-eabi-objcopy: stsJ3ObR/bin/thumbv7em-none-eabihf.o: No such file or directory with apparently no change to the archive file. The symbol is definitely in there: arm-none-eabi-objdump -x librustlib.a gives compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o: file format elf32-littlearm rw-r--r-- 0/0 10176 Dec 31 16:00 1969 compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o architecture: armv7e-m, flags 0x0011: ... SYMBOL TABLE: ldf *ABS* compiler_builtins.6207f1bb-cgu.122 ld .text.__aeabi_dcmpgt .text.__aeabi_dcmpgt ... g F .text.__aeabi_dcmpgt 0078 .hidden __aeabi_dcmpgt So the symbol is there, flagged as a Function, .hidden, but still global. Checking the contents of the archive: arm-none-eabi-ar tv librustlib.a | grep thumb it does appear that something is there: rw-r--r-- 0/0 22732 Dec 31 16:00 1969 bin/thumbv7em-none-eabihf.o When I try to extract everything in the archive: arm-none-eabi-ar x librustlib.a it extracts all objects up to that problem object with the '/' in the name, but none after it. -- 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 Alex Underwood changed: What|Removed |Added CC||alexander.underwood@okstate ||.edu --- Comment #2 from Alex Underwood --- Hello, I can also confirm this bug (still present in 2.37.50), and because the verilog output functionality is relevant to my work I figured I would take a crack at fixing it. As Olof said, the issue does seem to be because the verilog bfd_target uses BFD_ENDIAN_UNKNOWN, so the little-endianness check in the verilog_write_record function always fails and falls through to big-endian. That being said, verilog_write_record does support big- and little-endian, it just never reaches the little-endian section. 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? For example, a verilog-be and verilog-le format that use BFD_ENDIAN_BIG and BFD_ENDIAN_LITTLE respectively. This would leave it up to the user to specify the correct endianness for their given input bfd but at the same time I feel would help to alleviate an issue I've seen in several RISC-V projects in particular that take advantage of this bug and use objcopy as a way of switching endianness rather than just compiling the original files with the correct endianness setting at the GCC level. If that sounds like a reasonable approach, I'll get going on a patch to set that up. Though, that does leave the question of what to do with the current "verilog" target if it ends up split into 2 separate targets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 --- Comment #1 from Andrew Pullin --- This appears to originate from here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/ar.c;h=8885585ef7537450f0f0990a5eeea7eb16bcad8f;hb=refs/heads/master#l1157 As far as I can tell, there is no defined behavior for how archive files with a path containing a directory should behavior with the ar utility. afaik, `fopen()` has no facility for creating directories. Notably, if I do `mkdir bin` first, then the observed "No such file or directory" error will NOT be hit when using ar to extract, as now the pathname becomes valid. However: the issue remains with objcopy, since it apparently uses a temporary directory when doing an operation like `--localize-hidden`. Also of note: This appears to arise due to this archive file being created with `llvm-ar`, which does explicitely allow slashes in path name: https://releases.llvm.org/2.8/docs/CommandGuide/html/llvm-ar.html#:~:text=The%20path%20name%20is%20null%20terminated%20and%20may%20contain%20the%20slash%20(/)%20character. Using llvm-objcopy yields different behavior: the --localize-hidden operation succeeds without issue, despite the pathname containing a `/` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 --- Comment #2 from Alan Modra --- (In reply to Andrew Pullin from comment #1) > As far as I can tell, there is no defined behavior for how archive files > with a path containing a directory should behavior with the ar utility. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ar.html -- You are receiving this mail because: You are on the CC list for the bug.
