This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI


On Thu, Sep 13, 2018 at 5:32 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 13 Sep 2018, Arnd Bergmann wrote:
>
> > From what I can tell, mips64, riscv64, nios2, and microblaze are all wrong, and
> > the generic default would be wrong as well if picked up by anything else (but
> > nothing seems to use it).
>
> A question for cleaning this up and possibly unifying versions of this
> header: for multi-ABI architectures, in userspace, what are these
> structures meant to refer to?  The structures that would be produced by a
> core dump for the current process, as opposed to those that might be
> produced by a core dump for another ABI?

The structures match the process that they describe. We use them for
three distinct things in the kernel:

/proc/kcore describes the kernel itself, in core dump format that can
be used with gdb etc to look at the currently running kernel

/proc/vmcore can be used for crash dump analysis when a kernel
crashes and we restart into a new kernel (kdump), making the
crashed one available in the same format

Core files generated by the kernel for running processes (the most
common case). A 32-bit task running on a 64-bit kernel should produce
the same core file as one running on a 32-bit kernel. At least that's
what the code is trying to do, looking up the sources I came across
a patch for a bug in that area[1]

> I can confirm that the struct elf_prpsinfo defined in sys/procfs.h for
> MIPS n64 has size 0x90 whereas an n64 core dump has data size 0x88 for
> NT_PRPSINFO, indicating the pr_uid / pr_gid types are indeed wrong.  But
> I'm concerned here about n32 and about other fields in the structure.
> The code (dating back to the original addition of support for 64-bit MIPS
> ABIs to glibc in 2003) uses type unsigned long long int for pr_flag for
> n32.  But if I core dump an n32 process, I get 0x80 for the size of
> NT_PRPSINFO (while the userspace structure has size 0x88).  And similarly
> there are n32 conditionals in struct elf_prstatus - the core dump has size
> 0x1b8 for NT_PRSTATUS but the userspace structure has size 0x1c0.  If the
> structure is meant to correspond to the current ABI, that suggests those
> n32 conditionals are wrong (the conditional on the definition of
> elf_greg_t, however, is correct, as n32 does use 64-bit registers).

We have four definitions in the kernel for these structures: The native
structure for the ELF implementation [2], the generic compat implementation[3]
for everything other than MIPS, and the two MIPS variants [4][5].
Looking at the sources, the last three seem to use identical layouts,
aside from the elf_gregset_t, which uses 64-bit registers on n64 but
32-bit registers everywhere else, and the architecture specific
ELF_NGREG constant.

         Arnd

[1] https://www.linux-mips.org/archives/linux-mips/2009-05/msg00135.html
[2] https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/elfcore.h
[3] https://elixir.bootlin.com/linux/latest/source/include/linux/elfcore-compat.h
[4] https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/binfmt_elfo32.c
[5] https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/binfmt_elfn32.c


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]