public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] gas: Generate a new section for SHF_GNU_RETAIN
Date: Fri, 4 Dec 2020 15:29:07 +0000	[thread overview]
Message-ID: <20201204152907.mhls5ilpv47bj5fq@jozef-acer-manjaro> (raw)
In-Reply-To: <20201204135254.2147243-1-hjl.tools@gmail.com>

On Fri, Dec 04, 2020 at 05:52:54AM -0800, H.J. Lu wrote:
> For
> 	.globl	foo2
> 	.section	.data.foo,"aR"
> 	.align 4
> 	.type	foo2, @object
> 	.size	foo2, 4
> foo2:
> 	.long	2
> 	.globl	foo1
> 	.section	.data.foo
> 	.align 4
> 	.type	foo1, @object
> 	.size	foo1, 4
> foo1:
> 	.long	1
> 
> generate a new section if the SHF_GNU_RETAIN bit doesn't match.
> 
> 	* config/obj-elf.c (SEC_ASSEMBLER_SHF_MASK): New.
> 	(get_section_by_match): Also check if SEC_ASSEMBLER_SHF_MASK of
> 	sh_flags matches.  Rename info to sh_info.
> 	(obj_elf_change_section): Rename info to sh_info.
> 	(obj_elf_section): Rename info to sh_info.  Set sh_flags for
> 	SHF_GNU_RETAIN.
> 	* config/obj-elf.h (elf_section_match): Rename info to sh_info.
> 	Add sh_flags.
> 	* testsuite/gas/elf/elf.exp: Run section27.
> 	* testsuite/gas/elf/section24b.d: Updated.
> 	* testsuite/gas/elf/section27.d: New file.
> 	* testsuite/gas/elf/section27.s: Likewise.
> ---
>  gas/config/obj-elf.c               | 21 ++++++++++++------
>  gas/config/obj-elf.h               |  3 ++-
>  gas/testsuite/gas/elf/elf.exp      |  1 +
>  gas/testsuite/gas/elf/section24b.d | 10 ++++++---
>  gas/testsuite/gas/elf/section27.d  | 14 ++++++++++++
>  gas/testsuite/gas/elf/section27.s  | 34 ++++++++++++++++++++++++++++++
>  6 files changed, 73 insertions(+), 10 deletions(-)
>  create mode 100644 gas/testsuite/gas/elf/section27.d
>  create mode 100644 gas/testsuite/gas/elf/section27.s

I just want to check that we are OK with the fact that a .section
directive without any flags will always use the default flags, even if
the section previously had the 'R' flag set. I suppose this is just
standard behavior and how the .section directive has always behaved.

$ cat asm-tester.s
.section .data.foo,"awR"
.word 0
.section .data.foo
.word 0
$ as asm-tester.s -o tester.o
$ readelf --wide -S tester.o
...
  [ 4] .data.foo         PROGBITS        0000000000000000 000040 000002 00 WAR  0   0  1
  [ 5] .data.foo         PROGBITS        0000000000000000 000042 000002 00  WA  0   0  1
...

Also, I think the following change should be added, since the OR'ing of
SHF_GNU_RETAIN flag between sections, from the original patch, is now
redundant.

diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
index 54d42d9ecb..9ac53e4d0e 100644
--- a/gas/config/obj-elf.c
+++ b/gas/config/obj-elf.c
@@ -806,17 +806,9 @@ obj_elf_change_section (const char *name,
 		as_bad (_("changed section attributes for %s"), name);
 	    }
 	  else
-	    {
-	      /* Don't overwrite a previously set SHF_GNU_RETAIN flag for the
-		 section.  The entire section must be marked retained.  */
-	      if ((elf_tdata (stdoutput)->has_gnu_osabi & elf_gnu_osabi_retain)
-		  && ((elf_section_flags (old_sec) & SHF_GNU_RETAIN)))
-		attr |= SHF_GNU_RETAIN;
-
-	      /* FIXME: Maybe we should consider removing a previously set
-		 processor or application specific attribute as suspicious ?  */
-	      elf_section_flags (sec) = attr;
-	    }
+	    /* FIXME: Maybe we should consider removing a previously set
+	       processor or application specific attribute as suspicious ?  */
+	    elf_section_flags (sec) = attr;
 
 	  if ((flags & SEC_MERGE) && old_sec->entsize != (unsigned) entsize)
 	    as_bad (_("changed section entity size for %s"), name);

Thanks,
Jozef

  reply	other threads:[~2020-12-04 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 13:52 H.J. Lu
2020-12-04 15:29 ` Jozef Lawrynowicz [this message]
2020-12-04 16:43   ` V2 " H.J. Lu
2020-12-08 12:33     ` H.J. Lu
2020-12-08 17:08       ` Nick Clifton
2020-12-09  0:05         ` V3 " H.J. Lu
2020-12-09  0:37           ` Alan Modra

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=20201204152907.mhls5ilpv47bj5fq@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /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).