+shivang, lianbo
Adding shivang, he can review/add details if needed
On 25/11/06 04:06PM, Tao Liu wrote:
> > <...snip...>
>
> Regarding to v1's discussion, we cannot run abiv1 program on abiv2
> kernel, it's because abiv1 is big-endian and abiv2 is little-endian, and
> abiv2, or ppc64le kernel doesn't support big-endian, or abiv1 program
> cannot run upon it, see the following:
>
> $ file blkid
> blkid: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power ELF V1
> ABI, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0,
> BuildID[sha1]=b36e8a2a5e4d27039591a35fca38fa48735f5540, stripped
> $ ~/qemu-10.1.2/build/qemu-ppc64 ./blkid
> /dev/mapper/root: UUID="..." TYPE="xfs"
> /dev/sda3: UUID="..." TYPE="LVM2_member" PARTUUID="..."
> /dev/sda2: UUID="..." TYPE="xfs" PARTUUID="..."
> /dev/mapper/swap: UUID="..." TYPE="swap"
> /dev/mapper/home: UUID="..." TYPE="xfs"
> /dev/sda1: PARTUUID="..."
> $ ./blkid
> -bash: ./blkid: cannot execute binary file: Exec format error
> $ uname -a
> Linux 6.12.0-150.el10.ppc64le #1 SMP Fri Oct 31 06:58:14 EDT 2025 ppc64le
> GNU/Linux
> $ file /bin/bash
> /bin/bash: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500,
> OpenPOWER ELF V2 ABI, version 1 (SYSV), dynamically linked, interpreter
> /lib64/ld64.so.2, BuildID[sha1]=9ab800028ced16c5974f5b19cb6ed754178802a8, for
> GNU/Linux 3.10.0, stripped
>
> The abiv1 program blkid cannot be run on this machine, except with the
> help of qemu. So from my view, we don't need to consider the case that abiv2
> kernel might containing a abiv1 program or .ko.
>
> Please feel free to correct me if I'm wrong. @Aditya Gupta
Yes Tao, that looks correct to me. I also don't think we need consider
the incompatible abiv1<->abiv2 or little-endian<->big-endian kernel and
userspace cases.
About abiv1 always being big endian, i don't recall. Will go back and
read, but I don't think we need to consider abiv2 kernel running abiv1
program, I will give it a try if such case can exist.
>
> ---
> defs.h | 3 ++-
> netdump.c | 14 ++++++++++----
> ppc64.c | 34 +++++++++++++++++++++++++++++++---
> symbols.c | 5 +++--
> 4 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/defs.h b/defs.h
> index ab4aee8..19dff88 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -4699,6 +4699,7 @@ struct efi_memory_desc_t {
> #define MSR_PR_LG 14 /* Problem State / Privilege Level */
> /* Used to find the user or kernel-mode frame*/
>
> +#define STACK_SWITCH_FRAME_REGS 48
> #define STACK_FRAME_OVERHEAD 112
> #define EXCP_FRAME_MARKER 0x7265677368657265
>
> > <...snip...>
>
> @@ -3035,6 +3036,25 @@ ppc64_get_sp(ulong task)
> return sp;
> }
>
> +static bool
> +is_ppc64_elf_abi_v2(void)
> +{
> + static bool ret = false;
> + static bool checked = false;
> +
> + if (checked)
> + return ret;
> + switch (file_elf_header(pc->namelist, "e_flags")) {
> + case 2:
> + ret = true;
> + case 1:
> + break;
> + default:
> + error(WARNING, "Unknown e_flags for v1/v2 elf_abi
> detection.\n");
> + }
> + checked = true;
> + return ret;
> +}
>
> /*
> * get the SP and PC values for idle tasks.
> @@ -3056,9 +3076,17 @@ get_ppc64_frame(struct bt_info *bt, ulong *getpc,
> ulong *getsp)
> sp = ppc64_get_sp(task);
> if (!INSTACK(sp, bt))
> goto out;
> - readmem(sp+STACK_FRAME_OVERHEAD, KVADDR, ®s,
> - sizeof(struct ppc64_pt_regs),
> - "PPC64 pt_regs", FAULT_ON_ERROR);
> +
> + if (THIS_KERNEL_VERSION >= LINUX(6,2,0) && is_ppc64_elf_abi_v2()) {
Did the issue only occur with 6.2.0+ or is it dependent only on the
vmlinux being abiv2 ? Sorry i don't recall whether previous kernels were
compiled with abiv1 always.
> + readmem(sp+STACK_SWITCH_FRAME_REGS, KVADDR, ®s,
> + sizeof(struct ppc64_pt_regs),
> + "PPC64 pt_regs", FAULT_ON_ERROR);
> + } else {
> + readmem(sp+STACK_FRAME_OVERHEAD, KVADDR, ®s,
> + sizeof(struct ppc64_pt_regs),
> + "PPC64 pt_regs", FAULT_ON_ERROR);
> + }
> +
> ip = regs.nip;
> closest = closest_symbol(ip);
> if (STREQ(closest, ".__switch_to") || STREQ(closest, "__switch_to")) {
> diff --git a/symbols.c b/symbols.c
> index 480fdb6..0a11c2f 100644
> --- a/symbols.c
> +++ b/symbols.c
> @@ -217,7 +217,7 @@ symtab_init(void)
> * Check whether the namelist is a kerntypes file built by
> * dwarfextract, which places a magic number in e_version.
> */
> - if (file_elf_version(pc->namelist) == EV_DWARFEXTRACT)
> + if (file_elf_header(pc->namelist, "e_version") == EV_DWARFEXTRACT)
> pc->flags |= KERNTYPES;
>
> if (pc->flags & SYSMAP) {
> @@ -13149,7 +13149,8 @@ load_module_symbols(char *modref, char *namelist,
> ulong base_addr)
> error(FATAL, "cannot determine object file format: %s\n",
> namelist);
>
> - if (LKCD_KERNTYPES() && (file_elf_version(namelist) == EV_DWARFEXTRACT))
> + if (LKCD_KERNTYPES() &&
> + (file_elf_header(namelist, "e_version") == EV_DWARFEXTRACT))
> goto add_symbols; /* no symbols, add the debuginfo */
>
> if (!(bfd_get_file_flags(mbfd) & HAS_SYMS))
The patch looks good to me. Will test and respond.
Thanks Tao !
- Aditya G
> --
> 2.47.0
>
--
Crash-utility mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
