On Tue, Jun 29, 2021 at 03:32:15PM +0100, Steve McIntyre wrote:
Hi Adhemerval,
On Mon, Jun 28, 2021 at 04:37:34PM -0300, Adhemerval Zanella wrote:
Peter Jones from Red Hat (pjones@redhat.com ) seems to working on adding support for aarch64, by the last common on the thread. His work seems to be quite recent (6th may), so we might want to check with him if he is planning to finish this work.
AIUI Peter started hacking on this a while back, but he told me he was definitely looking for somebody to restart or pick it up. It's not really his area of expertise. I've added him in CC here...
Most of the work in that tree was done in 2019; in May I did a rebase to the current upstream tree and separated out the one relocation type (absolute, type 0) that we desperately need to work, and moved all the types where I'm wildly unsure of the implementation, and which we don't need with the *current* consumers, to their own patch on a different branch[0]. GitHub has made the conscious choice to show the wrong date on commits, and that's probably giving the impression I'm more actively working on this.
I'm happy to help in terms of what we need as consumers and why, and to any extent I'm able design and organization, but I don't have a lot of time to spend on this code and am not an expert on how it *should* be structured. In particular, the (internal to BFD) PE .h generation I've currently got, which tells our C files how our target is configured and thus is shared among various PE targets, is absolutely *craaaap*.
Another option might to check lld, we have it working on llvm for windows on aarch64. It might be ready available or require less adjustment than add the full binutils support.
It works for some things but not others. lld-link (the windows/PE targeting linker[1]) doesn't support several of the linker options we need which the ELF-targeting one does, in particular there's no concept like linker scripts and adding arbitrary sections was remarkably difficult when last I looked, as are simple things like _text/_etext symbols to mark the start and end of sections in a way you can reference directly from C code. That makes it hard to implement .vendor_cert and .sbat, notably including the SBAT self-check. The .vendor_cert problem is obnoxious, but the SBAT problems are a show-stopper. It also doesn't currently support EFI the EFI-specific machine types; edk2 post-processes the resulting binary to get EFI targets, which is exactly the sort of hacking we'd like to see less of[2].
We'd need to put work in there to make it useful as well.
Ideally it would be nice to have more than just objcopy/ld. At the moment debugging builds is awkward; objdump refuses to do anything useful with our binaries, for example.
Very true, and also at some point we definitely need to figure out something better than 'gcc -nostartfiles' to make a .so, and providing our startup files and C runtime as .a/.o files. Making it use target-specific startup files and crt0, so we can actually build real EFI binaries without having to link in a separate runtime tree, would be really nice. Right now, AFAIK gcc doesn't know about EFI targets at all, but *my* thinking has been that isn't even worth addressing with binutils in the state it's in. I bet I'm not the only one.
[0] https://github.com/vathpela/binutils/commit/45118328e907c6e81c61d4130df72d59... [1] It amazes me that clang got the "target is distinct from the linker binary you execute" thing completely right (unlike gcc) but lld got it completely wrong (mostly unlike binutils), but here we are. [2] That said, at this point I could do it trivially in the shim tree; we have a linter that can do this sort of thing.