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 (pjo...@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/45118328e907c6e81c61d4130df72d59d0f7c5c9
[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.

-- 
        Peter

_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to