From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7032 invoked by alias); 13 Sep 2018 20:31:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 4594 invoked by uid 89); 13 Sep 2018 20:31:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:wwwlin, sk:www.lin X-HELO: mail-qt0-f196.google.com MIME-Version: 1.0 References: <53924daa4b51c0d552d17d3c5fd9aea09f9fc4b2.1536720821.git.han_mao@c-sky.com> <20180913081721.GB4004@vmh-VirtualBox> In-Reply-To: From: Arnd Bergmann Date: Thu, 13 Sep 2018 20:31:00 -0000 Message-ID: Subject: Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI To: Joseph Myers Cc: Mao Han , gnu-csky@mentor.com, GNU C Library , c-sky_gcc_upstream@c-sky.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-09/txt/msg00197.txt.bz2 On Thu, Sep 13, 2018 at 5:32 PM Joseph Myers 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