Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] package/elf2flt: fix error when building gdb for target on m68k
@ 2023-01-17 15:35 Niklas Cassel via buildroot
  2023-02-05 14:15 ` Thomas Petazzoni via buildroot
  0 siblings, 1 reply; 2+ messages in thread
From: Niklas Cassel via buildroot @ 2023-01-17 15:35 UTC (permalink / raw)
  To: Thomas Petazzoni; +Cc: Niklas Cassel, buildroot

Thomas reported that m68k fails to build when enabling BR2_PACKAGE_GDB.

It fails when building gdb for the target with the following error:
elf2flt: ERROR: text=0x3c826 overlaps data=0x256e0 ?

It turns out that the gdb binary has another problematic input section
(.gcc_except_table), which causes elf2flt to try to append to the .text
output section, after it has already moved on with appending sections
to the .data output section.

elf2flt cannot append to a previous output section once it has moved on
to another output section.

Update the existing elf2flt patch to also add an exception for
.gcc_except_table.

Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
---
 ...l-error-regression-on-m68k-xtensa-ri.patch | 47 ++++++++++---------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/package/elf2flt/0005-elf2flt-fix-fatal-error-regression-on-m68k-xtensa-ri.patch b/package/elf2flt/0005-elf2flt-fix-fatal-error-regression-on-m68k-xtensa-ri.patch
index 278709cb1c..616bbc891f 100644
--- a/package/elf2flt/0005-elf2flt-fix-fatal-error-regression-on-m68k-xtensa-ri.patch
+++ b/package/elf2flt/0005-elf2flt-fix-fatal-error-regression-on-m68k-xtensa-ri.patch
@@ -1,8 +1,7 @@
-From 65ac5f9e69cfb989d970da74c41e478774d29be5 Mon Sep 17 00:00:00 2001
+From a8c9f650b82109abf7aa730f298ea5182ed62613 Mon Sep 17 00:00:00 2001
 From: Niklas Cassel <niklas.cassel@wdc.com>
 Date: Tue, 9 Aug 2022 21:06:05 +0200
-Subject: [PATCH] elf2flt: fix fatal error regression on m68k, xtensa,
- riscv64
+Subject: [PATCH] elf2flt: fix fatal error regression on m68k, xtensa, riscv64
 
 Commit ba379d08bb78 ("elf2flt: fix for segfault on some ARM ELFs")
 changed the condition of which input sections that should be included
@@ -12,16 +11,15 @@ to:
 ((a->flags & (SEC_DATA | SEC_READONLY | SEC_RELOC)) ==
 (SEC_DATA | SEC_READONLY | SEC_RELOC))
 
-On ARM, the .eh_frame input section does not have the SEC_RELOC flag
-set, so this specific change had no effect on ARM.
+On ARM, the .eh_frame input section does not have the SEC_RELOC flag set,
+so on ARM, this change caused .eh_frame to move from .text to .data.
 
-However, on e.g. m68k and riscv64, the .eh_frame input section does
-have the SEC_RELOC flag set, which means that after commit ba379d08bb78
-("elf2flt: fix for segfault on some ARM ELFs"), read-only relocation
-data sections were placed in .text output section, instead of .data
-output section.
+However, on e.g. m68k, xtensa and riscv64, the .eh_frame input section
+does have the SEC_RELOC flag set, which means that the change in
+commit ba379d08bb78 ("elf2flt: fix for segfault on some ARM ELFs")
+caused .eh_frame to move in an opposite way, i.e. from .data to .text.
 
-This will result in a fatal error on m68k, xtensa and riscv64:
+This resulted in a fatal error on m68k, xtensa and riscv64:
 ERROR: text=0x3bab8 overlaps data=0x33f60 ?
 
 This is because elf2flt cannot append to .text after .data has been
@@ -36,21 +34,26 @@ to .text after .data has been appended to (which will require elf2flt
 to move/relocate everything that has already been appended to .data,
 since the virtual addresses are contiguous).
 
-However, for now, add an exception for m68k, xtensa and riscv64
-(specifically for the problematic input section, .eh_frame), so that we
-get the same behavior as older elf2flt releases, where we put read-only
-relocation data in .data, which was working perfectly fine.
+However, for now, add an exception for input sections which have all
+three flags SEC_DATA, SEC_READONLY, and SEC_RELOC set, and which have a
+name equal to a problematic input section (.eh_frame, .gcc_except_table).
+That way, we get the same behavior as older elf2flt releases for m68k,
+xtensa and riscv64, where we put read-only relocation data in .data,
+which was working perfectly fine.
+
+This exception will not change any behavior on ARM, as the .eh_frame
+input section does not have flag SEC_RELOC set.
 
 Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
 ---
- elf2flt.c | 11 +++++++++--
- 1 file changed, 9 insertions(+), 2 deletions(-)
+ elf2flt.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/elf2flt.c b/elf2flt.c
-index 9c32f9a..a680c89 100644
+index e0d7891..39d035f 100644
 --- a/elf2flt.c
 +++ b/elf2flt.c
-@@ -340,8 +340,15 @@ compare_relocs (const void *pa, const void *pb)
+@@ -341,8 +341,13 @@ compare_relocs (const void *pa, const void *pb)
  static bool
  ro_reloc_data_section_should_be_in_text(asection *s)
  {
@@ -58,10 +61,8 @@ index 9c32f9a..a680c89 100644
 -	  (SEC_DATA | SEC_READONLY | SEC_RELOC);
 +  if ((s->flags & (SEC_DATA | SEC_READONLY | SEC_RELOC)) ==
 +      (SEC_DATA | SEC_READONLY | SEC_RELOC)) {
-+#if defined(TARGET_m68k) || defined(TARGET_riscv64) || defined(TARGET_xtensa)
-+    if (!strcmp(".eh_frame", s->name))
++    if (!strcmp(".eh_frame", s->name) || !strcmp(".gcc_except_table", s->name))
 +      return false;
-+#endif
 +    return true;
 +  }
 +  return false;
@@ -69,5 +70,5 @@ index 9c32f9a..a680c89 100644
  
  static uint32_t *
 -- 
-2.37.1
+2.39.0
 
-- 
2.39.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [Buildroot] [PATCH] package/elf2flt: fix error when building gdb for target on m68k
  2023-01-17 15:35 [Buildroot] [PATCH] package/elf2flt: fix error when building gdb for target on m68k Niklas Cassel via buildroot
@ 2023-02-05 14:15 ` Thomas Petazzoni via buildroot
  0 siblings, 0 replies; 2+ messages in thread
From: Thomas Petazzoni via buildroot @ 2023-02-05 14:15 UTC (permalink / raw)
  To: Niklas Cassel via buildroot; +Cc: Niklas Cassel

Hello Niklas,

On Tue, 17 Jan 2023 16:35:03 +0100
Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:

> Thomas reported that m68k fails to build when enabling BR2_PACKAGE_GDB.
> 
> It fails when building gdb for the target with the following error:
> elf2flt: ERROR: text=0x3c826 overlaps data=0x256e0 ?
> 
> It turns out that the gdb binary has another problematic input section
> (.gcc_except_table), which causes elf2flt to try to append to the .text
> output section, after it has already moved on with appending sections
> to the .data output section.
> 
> elf2flt cannot append to a previous output section once it has moved on
> to another output section.
> 
> Update the existing elf2flt patch to also add an exception for
> .gcc_except_table.
> 
> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> ---
>  ...l-error-regression-on-m68k-xtensa-ri.patch | 47 ++++++++++---------
>  1 file changed, 24 insertions(+), 23 deletions(-)

Many, many thanks for looking into this. It's a bit annoying that those
special sections have to be special-cased. Hopefully this will not
encounter too many of those special cases.

In the mean time, I've applied your patch to master. Thanks again!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-02-05 14:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-17 15:35 [Buildroot] [PATCH] package/elf2flt: fix error when building gdb for target on m68k Niklas Cassel via buildroot
2023-02-05 14:15 ` Thomas Petazzoni via buildroot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox