[gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[H.J. Lu]

Backport the following patches to add SHT_RELR (.relr.dyn) section support
to gdb-11-branch.

OK for gdb-11-branch?

Thanks.

H.J.
---
Fangrui Song (3):
  readelf: Support RELR in -S and -d and output
  readelf: Support SHT_RELR/DT_RELR for -r
  bfd_section_from_shdr: Support SHT_RELR sections

 bfd/elf.c              | 15 ++++++++++++---
 include/elf/common.h   |  6 +++++-
 include/elf/external.h |  8 ++++++++
 3 files changed, 25 insertions(+), 4 deletions(-)

-- 
2.34.1

[gdb-11-branch: Patch 1/3] readelf: Support RELR in -S and -d and output

[H.J. Lu]

From: Fangrui Song <maskray@google.com>

readelf -r dumping support is not added in this patch.

include/
	* elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT}
bfd/
	* elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}.

(cherry picked from commit dd207c1302d28d2d2b33cff058bb3fbf5138b480)
---
 bfd/elf.c            | 3 +++
 include/elf/common.h | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/bfd/elf.c b/bfd/elf.c
index 8f6531f23cf..3d9c5ff03cc 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -1773,6 +1773,9 @@ _bfd_elf_print_private_bfd_data (bfd *abfd, void *farg)
 	    case DT_REL: name = "REL"; break;
 	    case DT_RELSZ: name = "RELSZ"; break;
 	    case DT_RELENT: name = "RELENT"; break;
+	    case DT_RELR: name = "RELR"; break;
+	    case DT_RELRSZ: name = "RELRSZ"; break;
+	    case DT_RELRENT: name = "RELRENT"; break;
 	    case DT_PLTREL: name = "PLTREL"; break;
 	    case DT_DEBUG: name = "DEBUG"; break;
 	    case DT_TEXTREL: name = "TEXTREL"; break;
diff --git a/include/elf/common.h b/include/elf/common.h
index 7eefef9c7c4..8c6a595fea4 100644
--- a/include/elf/common.h
+++ b/include/elf/common.h
@@ -523,6 +523,7 @@
 #define SHT_PREINIT_ARRAY 16		/* Array of ptrs to pre-init funcs */
 #define SHT_GROUP	  17		/* Section contains a section group */
 #define SHT_SYMTAB_SHNDX  18		/* Indices for SHN_XINDEX entries */
+#define SHT_RELR	  19		/* RELR relative relocations */
 
 #define SHT_LOOS	0x60000000	/* First of OS specific semantics */
 #define SHT_HIOS	0x6fffffff	/* Last of OS specific semantics */
@@ -1056,6 +1057,9 @@
 #define DT_PREINIT_ARRAY   32
 #define DT_PREINIT_ARRAYSZ 33
 #define DT_SYMTAB_SHNDX    34
+#define DT_RELRSZ	35
+#define DT_RELR		36
+#define DT_RELRENT	37
 
 /* Note, the Oct 4, 1999 draft of the ELF ABI changed the values
    for DT_LOOS and DT_HIOS.  Some implementations however, use
-- 
2.34.1

[gdb-11-branch: Patch 2/3] readelf: Support SHT_RELR/DT_RELR for -r

[H.J. Lu]

From: Fangrui Song <maskray@google.com>

The -r output for SHT_RELR looks like:

Relocation section '.relr.dyn' at offset 0x530 contains 4 entries:
  7 offsets
00000000000028c0
00000000000028c8
0000000000003ad0
0000000000003ad8
0000000000003ae0
0000000000003ae8
0000000000003af0

For --use-dynamic, the header looks like

    'RELR' relocation section at offset 0x530 contains 32 bytes:

include/
    * elf/common.h (DT_ENCODING): Bump to 38.
    * elf/external.h (Elf32_External_Relr): New.
    (Elf64_External_Relr): New.

(cherry picked from commit a7fd11862703e45d2774981a4888bc127d473b06)
---
 include/elf/common.h   | 2 +-
 include/elf/external.h | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/elf/common.h b/include/elf/common.h
index 8c6a595fea4..dff90c4d9e1 100644
--- a/include/elf/common.h
+++ b/include/elf/common.h
@@ -1053,13 +1053,13 @@
 #define DT_FINI_ARRAYSZ 28
 #define DT_RUNPATH	29
 #define DT_FLAGS	30
-#define DT_ENCODING	32
 #define DT_PREINIT_ARRAY   32
 #define DT_PREINIT_ARRAYSZ 33
 #define DT_SYMTAB_SHNDX    34
 #define DT_RELRSZ	35
 #define DT_RELR		36
 #define DT_RELRENT	37
+#define DT_ENCODING	38
 
 /* Note, the Oct 4, 1999 draft of the ELF ABI changed the values
    for DT_LOOS and DT_HIOS.  Some implementations however, use
diff --git a/include/elf/external.h b/include/elf/external.h
index b24985687e6..815e39c2837 100644
--- a/include/elf/external.h
+++ b/include/elf/external.h
@@ -211,6 +211,10 @@ typedef struct {
   unsigned char	r_addend[4];	/* Constant addend used to compute value */
 } Elf32_External_Rela;
 
+typedef struct {
+  unsigned char r_data[4];	/* RELR entry */
+} Elf32_External_Relr;
+
 typedef struct {
   unsigned char r_offset[8];	/* Location at which to apply the action */
   unsigned char	r_info[8];	/* index and type of relocation */
@@ -222,6 +226,10 @@ typedef struct {
   unsigned char	r_addend[8];	/* Constant addend used to compute value */
 } Elf64_External_Rela;
 
+typedef struct {
+  unsigned char r_data[8];	/* RELR entry */
+} Elf64_External_Relr;
+
 /* dynamic section structure */
 
 typedef struct {
-- 
2.34.1

[gdb-11-branch: Patch 3/3] bfd_section_from_shdr: Support SHT_RELR sections

[H.J. Lu]

From: Fangrui Song <maskray@google.com>

If a.so contains an SHT_RELR section, objcopy a.so will fail with:

    a.so: unknown type [0x13] section `.relr.dyn'

This change allows objcopy to work.

bfd/
    * elf.c (bfd_section_from_shdr): Support SHT_RELR.

(cherry picked from commit a619b58721f0a03fd91c27670d3e4c2fb0d88f1e)
---
 bfd/elf.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/bfd/elf.c b/bfd/elf.c
index 3d9c5ff03cc..985167fd85c 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -2358,16 +2358,22 @@ bfd_section_from_shdr (bfd *abfd, unsigned int shindex)
 
     case SHT_REL:
     case SHT_RELA:
+    case SHT_RELR:
       /* *These* do a lot of work -- but build no sections!  */
       {
 	asection *target_sect;
 	Elf_Internal_Shdr *hdr2, **p_hdr;
 	unsigned int num_sec = elf_numsections (abfd);
 	struct bfd_elf_section_data *esdt;
+	bfd_size_type size;
 
-	if (hdr->sh_entsize
-	    != (bfd_size_type) (hdr->sh_type == SHT_REL
-				? bed->s->sizeof_rel : bed->s->sizeof_rela))
+	if (hdr->sh_type == SHT_REL)
+	  size = bed->s->sizeof_rel;
+	else if (hdr->sh_type == SHT_RELA)
+	  size = bed->s->sizeof_rela;
+	else
+	  size = bed->s->arch_size / 8;
+	if (hdr->sh_entsize != size)
 	  goto fail;
 
 	/* Check for a bogus link to avoid crashing.  */
-- 
2.34.1

Re: [gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[Simon Marchi]

On 2022-01-09 12:45, H.J. Lu via Gdb-patches wrote:
> Backport the following patches to add SHT_RELR (.relr.dyn) section support
> to gdb-11-branch.
> 
> OK for gdb-11-branch?

There's no changes specific to GDB, but since you CC'ed gdb-patches: no problem from the GDB side.

Simon

Re: [gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[H.J. Lu]

On Sun, Jan 9, 2022 at 6:44 PM Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
>
>
> On 2022-01-09 12:45, H.J. Lu via Gdb-patches wrote:
> > Backport the following patches to add SHT_RELR (.relr.dyn) section support
> > to gdb-11-branch.
> >
> > OK for gdb-11-branch?
>
> There's no changes specific to GDB, but since you CC'ed gdb-patches: no problem from the GDB side.
>
> Simon

I am checking them in.

-- 
H.J.

Re: [gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[Joel Brobecker]

> > > Backport the following patches to add SHT_RELR (.relr.dyn) section support
> > > to gdb-11-branch.
> > >
> > > OK for gdb-11-branch?
[...]
> I am checking them in.

Just a heads up that, to backport changes to a GDB branch after
the first release was done, we should create a GDB/PR and set
the target milestone to the corresponding release. Otherwise,
the announcement is going to miss the fact that this change
was included in the release.

If you see my email as I'm sending it, can you take care of this
right away? Otherwise, I'll create one, but I cannot be as informative
as you might be, and that's one of the main point of having those PRs.

-- 
Joel

Re: [gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[Joel Brobecker]

> Just a heads up that, to backport changes to a GDB branch after
> the first release was done, we should create a GDB/PR and set
> the target milestone to the corresponding release. Otherwise,
> the announcement is going to miss the fact that this change
> was included in the release.
> 
> If you see my email as I'm sending it, can you take care of this
> right away? Otherwise, I'll create one, but I cannot be as informative
> as you might be, and that's one of the main point of having those PRs.

I am about to start working on making the GDB 11.2 release, so
I've created the following PR, to have it ready:
https://sourceware.org/bugzilla/show_bug.cgi?id=28785

Something that also became more obvious to me as I created the PR
and would have been useful in assessing whether or not we should
backport the patches is an explanation of why we should be backporting
them. The commits make it sound like they are about fixing readelf
and objcopy, which makes me wonder why you proposed them for a GDB
release.

Can you update the PR so as to provide more information there, please?

-- 
Joel

Re: [gdb-11-branch: Patch 0/3] Support SHT_RELR (.relr.dyn) section

[H.J. Lu]

On Sun, Jan 16, 2022 at 2:21 AM Joel Brobecker <brobecker@adacore.com> wrote:
>
> > Just a heads up that, to backport changes to a GDB branch after
> > the first release was done, we should create a GDB/PR and set
> > the target milestone to the corresponding release. Otherwise,
> > the announcement is going to miss the fact that this change
> > was included in the release.
> >
> > If you see my email as I'm sending it, can you take care of this
> > right away? Otherwise, I'll create one, but I cannot be as informative
> > as you might be, and that's one of the main point of having those PRs.
>
> I am about to start working on making the GDB 11.2 release, so
> I've created the following PR, to have it ready:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28785
>
> Something that also became more obvious to me as I created the PR
> and would have been useful in assessing whether or not we should
> backport the patches is an explanation of why we should be backporting
> them. The commits make it sound like they are about fixing readelf
> and objcopy, which makes me wonder why you proposed them for a GDB
> release.
>
> Can you update the PR so as to provide more information there, please?
>

It is a dup of

https://sourceware.org/bugzilla/show_bug.cgi?id=28758

-- 
H.J.