[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #18 from Tamar Christina --- (In reply to Steve McIntyre from comment #17) > (In reply to Tamar Christina from comment #16) > qemu-system-aarch64 -m 2048 --enable-kvm -vga none -nographic -machine > virt,gic-version=host,kernel_irqchip=on -cpu host -pflash aarch64-OVMF.fd > -pflash aarch64-storage.fd Found the problem, it seems I needed -cpu cortex-a57, it now drops me to the shell. But when I try to run my hello world I get a rather vague Shell> fs0:hello.efi Command Error Status: Not Found I am 80% sure it's the linkerscript, as binutils is able to read and understand the format as produced by clang+lld fine. > file hello.efi hello.efi: PE32+ executable (EFI application) (stripped to external PDB), for MS Windows > objdump -h hello.efi hello.efi: file format pei-littleaarch64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 5bb0 2000 2000 0400 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 1d80 8000 8000 6000 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .dynamic 00f0 a000 a000 7e00 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .rela 0e58 b000 b000 8000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynsym 0138 c000 c000 9000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA But afraid I don't know enough about EFI to debug the script. Is there a tool I can use to validate the binary or figure out what that error means? -- 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 #19 from pjones at redhat dot com --- Can you share your tree so we can replicate this locally? Aside from that, "objdump -f" or even "objdump -x" would be helpful. My initial suspicion is that it's not seeing your binary as relocatable, and EFI_NOT_FOUND is coming from edk2's GetPeCoffImageFixLoadingAssignedAddress(), indicating that the fixed load address is not available. On other arches we solve this with a dummy .reloc section in crt0-efi-ARCH.S (such as this https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/crt0-efi-x86_64.S#L65 ), and of course you'll need the .reloc section in the linker script (such as https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/elf_x86_64_efi.lds#L28 ). -- 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 #20 from Tamar Christina --- (In reply to pjo...@redhat.com from comment #19) > Can you share your tree so we can replicate this locally? Aside from that, > "objdump -f" or even "objdump -x" would be helpful. > Yes, I'll do some cleanup and push it to a branch on binutils. > My initial suspicion is that it's not seeing your binary as relocatable, and > EFI_NOT_FOUND is coming from edk2's > GetPeCoffImageFixLoadingAssignedAddress(), indicating that the fixed load > address is not available. On other arches we solve this with a dummy .reloc > section in crt0-efi-ARCH.S (such as this > https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/crt0-efi-x86_64. > S#L65 ), and of course you'll need the .reloc section in the linker script > (such as > https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/elf_x86_64_efi. > lds#L28 ). Ah that would explain it. I didn't add that part in when I removed the PE creation code from crt0-efi-aarch64.S. -- You are receiving this mail because: You are on the CC list for the bug.
[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 #11 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=068a039b8bd7c7386bb0d88f0ae245b0fe4132e9 commit 068a039b8bd7c7386bb0d88f0ae245b0fe4132e9 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. -- 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 #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c7fdac09d919aaf86d302e6c622de6ee000c1b7c commit c7fdac09d919aaf86d302e6c622de6ee000c1b7c 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. -- You are receiving this mail because: You are on the CC list for the bug.
