public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@google.com>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH v4] PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE
Date: Sun, 9 Jul 2023 10:46:10 -0700	[thread overview]
Message-ID: <20230709174610.fidml5vy4ue6leme@google.com> (raw)
In-Reply-To: <ZKq3ly5Jboj9fJB4@squeak.grove.modra.org>

On 2023-07-09, Alan Modra wrote:
>On Fri, Jul 07, 2023 at 10:30:35PM -0700, Fangrui Song via Binutils wrote:
>> +static bool
>> +elf_x86_64_copy_private_section_data (bfd *ibfd ATTRIBUTE_UNUSED,
>> +				      asection *isec,
>> +				      bfd *obfd ATTRIBUTE_UNUSED,
>> +				      asection *osec) {
>> +  /* objcopy --set-section-flags without "large" drops SHF_X86_64_LARGE.  */
>> +  elf_section_flags (osec) = (elf_section_flags (isec) & ~SHF_X86_64_LARGE);
>> +
>> +  return true;
>> +}
>> +
>
>Unlike the other two functions, this one replaces the standard
>_bfd_elf_copy_private_section_data.  You'll want to call it, and
>distinguish between a call from objcopy.c and a call from ldwrite.c.
>I think you're OK accessing elf_section_flags for osec without first
>checking for an elf bfd, because bfd_copy_private_section_data invokes
>the obfd xvec function.  Like this:
>
>static bool
>elf_x86_64_copy_private_section_data (bfd *ibfd, asection *isec,
>				      bfd *obfd, asection *osec)
>{
>  if (!_bfd_elf_copy_private_section_data (ibfd, isec, obfd, osec))
>    return false;
>
>  /* objcopy --set-section-flags without "large" drops SHF_X86_64_LARGE.  */
>  if (ibfd != obfd)
>    elf_section_flags (osec) &= ~SHF_X86_64_LARGE;
>
>  return true;
>}
>
>The patch looks OK to me with the above replacement.

Thank you.  I see that we need to call _bfd_elf_copy_private_section_data  first to
respect a few other properties including sh_entsize and "readonly".

For objcopy -I binary -O elf64-x86-64 pr25749-2.c a.o,
ibfd may not be an ELF bfd, but obfd is guaranteed to be an ELF bfd.

ld/ldwrite.c calls bfd_copy_private_section_data with ibfd == obfd.

  reply	other threads:[~2023-07-09 17:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-08  5:30 Fangrui Song
2023-07-09 13:35 ` Alan Modra
2023-07-09 17:46   ` Fangrui Song [this message]
2023-07-10  6:37 ` Jan Beulich
2023-07-10 18:07   ` Fangrui Song
2023-07-12 14:32     ` Jan Beulich
2023-07-12 15:42       ` Fangrui Song

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=20230709174610.fidml5vy4ue6leme@google.com \
    --to=maskray@google.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /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).