On Mon, Sep 17, 2018 at 5:05 AM Joseph Myers wrote:
>
> On Fri, 14 Sep 2018, Arnd Bergmann wrote:
>
> > +typedef unsigned long elf_greg_t;
>
> Does that need to be unsigned long long for x32? (At least glibc thinks
> so; I've not tested what an x32 core dump actually looks like, but to be
> usefu
On Fri, 14 Sep 2018, Arnd Bergmann wrote:
> +typedef unsigned long elf_greg_t;
Does that need to be unsigned long long for x32? (At least glibc thinks
so; I've not tested what an x32 core dump actually looks like, but to be
useful it certainly ought to have 64-bit registers.)
--
Joseph S. My
* Arnd Bergmann wrote:
> diff --git a/arch/x86/include/uapi/asm/elf.h b/arch/x86/include/uapi/asm/elf.h
> new file mode 100644
> index ..a640e1224939
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/elf.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-
On Fri, Sep 14, 2018 at 7:45 PM Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > - Move required data from the private x86 asm/elf.h file into
> > a new uapi/asm/elf.h. Some other architectures already do that,
> > but most of them do not. Before applying the patch, we have
> > to do this fo
* Arnd Bergmann wrote:
> After finding a bug in glibc the question came up how linux/elfcore.h
> is supposed to be used from user space. As far as I can tell, it's
> not possible, as it references data types that are simply unavailable
> there.
>
> The #ifndef __KERNEL__ section in that header
After finding a bug in glibc the question came up how linux/elfcore.h
is supposed to be used from user space. As far as I can tell, it's
not possible, as it references data types that are simply unavailable
there.
The #ifndef __KERNEL__ section in that header dates back to when the
file was introd
6 matches
Mail list logo
