From: Palmer Dabbelt <palmer@dabbelt.com>
To: nelson@rivosinc.com
Cc: schwab@suse.de, binutils@sourceware.org
Subject: Re: [PATCH] Add basic support for RISC-V 64-bit EFI objects
Date: Fri, 25 Aug 2023 06:26:39 -0700 (PDT) [thread overview]
Message-ID: <mhng-ca150425-b1c1-4cb0-a83c-e499b801ad92@palmer-ri-x1c9> (raw)
In-Reply-To: <CAPpQWtD3txZZ3eezaaAtVfDz+sj=pW7+tAMcRSdzXWgNTW2SvA@mail.gmail.com>
On Thu, 24 Aug 2023 19:15:32 PDT (-0700), nelson@rivosinc.com wrote:
> On Wed, Aug 9, 2023 at 4:11 PM Andreas Schwab via Binutils <
> binutils@sourceware.org> wrote:
>
>> On Aug 08 2023, Palmer Dabbelt wrote:
>>
>> > So the idea is to just objcopy an ELF into a PE for EFI? IIUC that's
>> > generally the way to go for this sort of thing. In Linux we just have a
>> > PE header manually embedded in a flat binary, but presumably EFI folks
>> > want to have objcopy support for some reason?
>>
>> My main intention is to let BFD recognize EFI objects so that I can
>> objdump them easily. The support for objcopy comes in naturally, and
>> some packages do use objcopy to create EFI objects from ELF (on archs
>> where BFD supports it).
OK, that makes sense to me.
> Passed the binutils regression, and the pei-riscv64 testcase is also
> passed. I don't familiar with the COFF stuff, but at least the support of
> objdump and objcopy seems to be working, that's what I can check the most
> currently. Hope this helps before any expert comments appear ;)
So you think it's ready to merge, or did you want to look closer?
>
> Thanks
> Nelson
next prev parent reply other threads:[~2023-08-25 13:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 14:18 Andreas Schwab
2023-08-09 1:54 ` Palmer Dabbelt
2023-08-09 8:10 ` Andreas Schwab
2023-08-25 2:15 ` Nelson Chu
2023-08-25 13:26 ` Palmer Dabbelt [this message]
2023-08-28 2:03 ` Nelson Chu
2023-09-06 15:40 ` Palmer Dabbelt
2023-09-06 20:01 ` Peter Jones
2023-09-06 20:01 ` [PATCH] Handle "efi-app-riscv64" and similar targets in objcopy Peter Jones
2023-12-04 17:16 ` Palmer Dabbelt
2023-12-05 6:45 ` Nelson Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mhng-ca150425-b1c1-4cb0-a83c-e499b801ad92@palmer-ri-x1c9 \
--to=palmer@dabbelt.com \
--cc=binutils@sourceware.org \
--cc=nelson@rivosinc.com \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).