[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180915113733.GA35411@gmail.com>
Date: Sat, 15 Sep 2018 13:37:33 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
Joseph Myers <joseph@...esourcery.com>,
David Howells <dhowells@...hat.com>, libc-alpha@...rceware.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] making uapi/linux/elfcore.h useful again
* Arnd Bergmann <arnd@...db.de> wrote:
> diff --git a/arch/x86/include/uapi/asm/elf.h b/arch/x86/include/uapi/asm/elf.h
> new file mode 100644
> index 000000000000..a640e1224939
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/elf.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_ASM_X86_ELF_H
> +#define _UAPI_ASM_X86_ELF_H
> +
> +#ifdef __i386__
> +
> +/*
> + * These are used to set parameters in the core dumps.
> + */
> +#define ELF_CLASS ELFCLASS32
> +#define ELF_DATA ELFDATA2LSB
> +#define ELF_ARCH EM_386
> +#define ELF_NGREG 17
> +
> +#else
> +
> +/*
> + * These are used to set parameters in the core dumps.
> + */
> +#define ELF_CLASS ELFCLASS64
> +#define ELF_DATA ELFDATA2LSB
> +#define ELF_ARCH EM_X86_64
> +#define ELF_NGREG 27
> +
> +#endif /* __i386__ */
> +
> +typedef unsigned long elf_greg_t;
> +typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> +
> +#endif
On a second thought, maybe deduplicate the comments? Something like:
/*
* These are used to set parameters in core dumps:
*/
#ifdef __i386__
# define ELF_CLASS ELFCLASS32
# define ELF_DATA ELFDATA2LSB
# define ELF_ARCH EM_386
# define ELF_NGREG 17
#else
# define ELF_CLASS ELFCLASS64
# define ELF_DATA ELFDATA2LSB
# define ELF_ARCH EM_X86_64
# define ELF_NGREG 27
#endif
Note:
- I fixed a typo in the comment.
- Aligned the blocks vertically for better visibility.
- The closing #endif comment became unnecessary as well, due to the much more obvious
structure when written this way.
The type changes/cleanups look good otherwise: it's quite probable that it was never directly
included in any user-space library in any sane fashion before, so it's not really an UAPI that
was relied on, as long as it doesn't break the build anywhere.
Thanks,
Ingo
Powered by blists - more mailing lists