When building with CONFIG_RELOCATABLE, there is a .interp section
which contains the name of the expected ELF interpreter:

Contents of section .interp:
 c0000000021c1bac 2f757372 2f6c6962 2f6c642e 736f2e31  /usr/lib/ld.so.1
 c0000000021c1bbc 00                                   .

That information is useless and even likely wrong. Remove it.

Link: https://github.com/linuxppc/issues/issues/434
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
 arch/powerpc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f3804103c56c..9753fb87217c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -101,7 +101,7 @@ KBUILD_LDFLAGS	+= -m elf$(BITS)$(LDEMULATION)
 endif
 
 LDFLAGS_vmlinux-y := -Bstatic
-LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
+LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie --no-dynamic-linker
 LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) += -z notext
 LDFLAGS_vmlinux	:= $(LDFLAGS_vmlinux-y)
 
-- 
2.49.0

While debugging a ppc64le QEMU guest on an x86_64 host, I observed GDB crashes
when attempting to attach to the remote target:

(gdb) target remote :1234

Investigation revealed that cross-compiling the Linux kernel for ppc64le on an
x86_64 host using Clang produces a vmlinux binary containing an empty .interp
section. This empty .interp section is responsible for the GDB crashes.

This issue does not occur when:
- Building for ppc64le target using GCC on x86_64 host
- Building for ppc64le target using Clang on ppc64le host  
- Building for ppc64le target using GCC on ppc64le host

For details refer [1]

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33481

vishalc

+CLANG ppl

Hi,

Le 13/10/2025 à 06:01, Vishal Chourasia a écrit :
> While debugging a ppc64le QEMU guest on an x86_64 host, I observed GDB crashes
> when attempting to attach to the remote target:
> 
> (gdb) target remote :1234
> 
> Investigation revealed that cross-compiling the Linux kernel for ppc64le on an
> x86_64 host using Clang produces a vmlinux binary containing an empty .interp
> section. This empty .interp section is responsible for the GDB crashes.

Which version of CLANG is it ?

> 
> This issue does not occur when:
> - Building for ppc64le target using GCC on x86_64 host
> - Building for ppc64le target using Clang on ppc64le host

Is it the same CLANG version ?

> - Building for ppc64le target using GCC on ppc64le host
> 
> For details refer [1]
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=33481

Christophe

On Mon, Oct 13, 2025 at 08:46:48AM +0200, Christophe Leroy wrote:
> +CLANG ppl
> 
> Hi,
> 
> Le 13/10/2025 à 06:01, Vishal Chourasia a écrit :
> > While debugging a ppc64le QEMU guest on an x86_64 host, I observed GDB crashes
> > when attempting to attach to the remote target:
> > 
> > (gdb) target remote :1234
> > 
> > Investigation revealed that cross-compiling the Linux kernel for ppc64le on an
> > x86_64 host using Clang produces a vmlinux binary containing an empty .interp
> > section. This empty .interp section is responsible for the GDB crashes.
> 
> Which version of CLANG is it ?
(i) ❯ clang --version
clang version 21.0.0git (https://github.com/llvm/llvm-project.git a80bccc6847be104948f46d313f03ac6b9ccb292)

> 
> > 
> > This issue does not occur when:
> > - Building for ppc64le target using GCC on x86_64 host
> > - Building for ppc64le target using Clang on ppc64le host
> 
> Is it the same CLANG version ?
# clang --version
clang version 22.0.0git (https://github.com/llvm/llvm-project.git 2f755c543ab357bd83235592fcee37fa391cdd9d)

> 
> > - Building for ppc64le target using GCC on ppc64le host
> > 
> > For details refer [1]
> > 
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=33481
> 

vishalc

Hi!

On Tue, Jul 01, 2025 at 12:49:29PM +0200, Christophe Leroy wrote:
> When building with CONFIG_RELOCATABLE, there is a .interp section
> which contains the name of the expected ELF interpreter:
> 
> Contents of section .interp:
>  c0000000021c1bac 2f757372 2f6c6962 2f6c642e 736f2e31  /usr/lib/ld.so.1
>  c0000000021c1bbc 00                                   .
> 
> That information is useless and even likely wrong. Remove it.

s/ likely//

You cannot run the kernel as some dynamic object (under control of some
interpreter that will load DSOs for you), hehe.

The various bfd/elf*.c (in binutils/ld) have code like

  if (htab->elf.dynamic_sections_created)
    {
      /* Set the contents of the .interp section to the interpreter.  */
      if (bfd_link_executable (info) && !info->nointerp)
        {
          s = bfd_get_linker_section (dynobj, ".interp");
          if (s == NULL)
            abort ();
          s->size = sizeof ELF_DYNAMIC_INTERPRETER;
          s->contents = (unsigned char *) ELF_DYNAMIC_INTERPRETER;
        }
    }

(yes there are about a hundred copies of this code, that could be
improved :-) )

whenever producing dynamic objects, so this code just sets that text and
that's all, no side effect to be worried of.

Acked-by: Segher Boessenkool <segher@kernel.crashing.org>

(Maybe this could or should be in generic code though, not architecture
code?)


Segher