On Mon, 27 Mar 2023, Geert Uytterhoeven wrote: > On Mon, Mar 27, 2023 at 2:47 AM Finn Thain <fth...@linux-m68k.org> wrote: > > I wasn't able to add the linux-m68k list to the bug report Cc list. > > > > I'm forwarding this as I don't know the answer to Tom's question... > > > > On Sat, 25 Mar 2023, tromey at sourceware dot org wrote: > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=30273 > > > > > > Tom Tromey <tromey at sourceware dot org> changed: > > > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > > CC| |tromey at sourceware dot > > > org > > > > > > --- Comment #1 from Tom Tromey <tromey at sourceware dot org> --- > > > This is probably a regression due to this patch: > > > > > > commit 3eba3a011a89c75c10bd1860eee4589e65697165 > > > Author: Tom Tromey <tro...@adacore.com> > > > Date: Mon Sep 14 08:30:10 2020 -0600 > > > > > > Various m68k fixes for gdb > > > > > > > > > When I debug gdb I see it decides this core file is > > > GDB_OSABI_SVR4, not GDB_OSABI_LINUX. This happens > > > because m68k_osabi_sniffer takes this branch: > > > > > > if (elfosabi == ELFOSABI_NONE) > > > return GDB_OSABI_SVR4; > > > > > > From elf/common.h: > > > > > > #define ELFOSABI_NONE 0 /* UNIX System V ABI */ > > > #define ELFOSABI_HPUX 1 /* HP-UX operating system */ > > > #define ELFOSABI_NETBSD 2 /* NetBSD */ > > > #define ELFOSABI_GNU 3 /* GNU */ > > > #define ELFOSABI_LINUX 3 /* Alias for ELFOSABI_GNU */ > > > > > > > > > So I guess one question is why this core file isn't marked > > > as ELFOSABI_LINUX. > > Only PA-RISC and the remoteproc core dumper seem to use > ELFOSABI_LINUX? > > arch/parisc/include/asm/elf.h:#define ELF_OSABI ELFOSABI_LINUX > arch/parisc/kernel/ptrace.c: .name = "parisc", .e_machine = > ELF_ARCH, .ei_osabi = ELFOSABI_LINUX, > arch/parisc/kernel/ptrace.c: .name = "parisc", .e_machine = > EM_PARISC, .ei_osabi = ELFOSABI_LINUX, > > include/uapi/linux/elf.h:#ifndef ELF_OSABI > include/uapi/linux/elf.h:#define ELF_OSABI ELFOSABI_NONE > include/uapi/linux/elf.h-#endif > > fs/proc/kcore.c: [EI_OSABI] = ELF_OSABI, > > drivers/remoteproc/remoteproc_elf_helpers.h: > hdr->e_ident[EI_OSABI] = ELFOSABI_NONE; > > Or perhaps it's set originally somewhere else, but overwritten on > m68k (and a few others)? > > arch/arm/kernel/ptrace.c: .name = "arm", .e_machine = > ELF_ARCH, .ei_osabi = ELF_OSABI, > arch/hexagon/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > arch/m68k/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > arch/mips/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > arch/mips/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > arch/mips/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > arch/nios2/kernel/ptrace.c: .ei_osabi = ELF_OSABI, > > Does this work on other architectures? >
I'm not sure that it matters. If Tom is right that the regression was caused by his commit 3eba3a011a89 then the issue would be confined to m68k and it's ABIs, and how to tell them apart given ELFOSABI_NONE: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3eba3a011a89 BTW, I suspect that the best place to discuss this would be bugzilla otherwise we'll need to Cc Tom.
