From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Raphael Gault <raphael.gault@arm.com>
Cc: raph.gault+kdev@gmail.com, peterz@infradead.org,
catalin.marinas@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
julien.thierry.kdev@gmail.com
Subject: Re: [RFC v4 04/18] objtool: arm64: Add required implementation for supporting the aarch64 architecture in objtool.
Date: Thu, 22 Aug 2019 15:00:51 -0500 [thread overview]
Message-ID: <20190822200051.in6qxtv23le6jrtf@treble> (raw)
In-Reply-To: <20190816122403.14994-5-raphael.gault@arm.com>
On Fri, Aug 16, 2019 at 01:23:49PM +0100, Raphael Gault wrote:
> diff --git a/tools/objtool/arch.h b/tools/objtool/arch.h
> index e91e12807678..bb5ce810fb6e 100644
> --- a/tools/objtool/arch.h
> +++ b/tools/objtool/arch.h
> @@ -62,9 +62,16 @@ struct op_src {
> int offset;
> };
>
> +struct op_extra {
> + unsigned char used;
> + unsigned char reg;
> + int offset;
> +};
> +
> struct stack_op {
> struct op_dest dest;
> struct op_src src;
> + struct op_extra extra;
Maybe the arch-specific data structure should just be named 'arch'
instead of 'extra'.
> --- /dev/null
> +++ b/tools/objtool/arch/arm64/include/arch_special.h
> @@ -0,0 +1,36 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +#ifndef _ARM64_ARCH_SPECIAL_H
> +#define _ARM64_ARCH_SPECIAL_H
> +
> +#define EX_ENTRY_SIZE 8
> +#define EX_ORIG_OFFSET 0
> +#define EX_NEW_OFFSET 4
> +
> +#define JUMP_ENTRY_SIZE 16
> +#define JUMP_ORIG_OFFSET 0
> +#define JUMP_NEW_OFFSET 4
> +
> +#define ALT_ENTRY_SIZE 12
> +#define ALT_ORIG_OFFSET 0
> +#define ALT_NEW_OFFSET 4
> +#define ALT_FEATURE_OFFSET 8
> +#define ALT_ORIG_LEN_OFFSET 10
> +#define ALT_NEW_LEN_OFFSET 11
> +
> +#define X86_FEATURE_POPCNT (4 * 32 + 23)
> +#define X86_FEATURE_SMAP (9 * 32 + 20)
It's weird to have these x86-specific macros here. I guess they're
needed to compile because the later patch hasn't abstracted it out yet.
This patch should really come later in the series, *after* all the
arch-specific bits have been abstracted out of the generic code.
> +
> +#endif /* _ARM64_ARCH_SPECIAL_H */
> diff --git a/tools/objtool/arch/arm64/include/asm/orc_types.h b/tools/objtool/arch/arm64/include/asm/orc_types.h
> new file mode 100644
> index 000000000000..9b04885eb785
> --- /dev/null
> +++ b/tools/objtool/arch/arm64/include/asm/orc_types.h
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2017 Josh Poimboeuf <jpoimboe@redhat.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef _ORC_TYPES_H
> +#define _ORC_TYPES_H
> +
> +#include <linux/types.h>
> +#include <linux/compiler.h>
> +
> +/*
> + * The ORC_REG_* registers are base registers which are used to find other
> + * registers on the stack.
> + *
> + * ORC_REG_PREV_SP, also known as DWARF Call Frame Address (CFA), is the
> + * address of the previous frame: the caller's SP before it called the current
> + * function.
> + *
> + * ORC_REG_UNDEFINED means the corresponding register's value didn't change in
> + * the current frame.
> + *
> + * The most commonly used base registers are SP and BP -- which the previous SP
> + * is usually based on -- and PREV_SP and UNDEFINED -- which the previous BP is
> + * usually based on.
> + *
> + * The rest of the base registers are needed for special cases like entry code
> + * and GCC realigned stacks.
> + */
> +#define ORC_REG_UNDEFINED 0
> +#define ORC_REG_PREV_SP 1
> +#define ORC_REG_DX 2
> +#define ORC_REG_DI 3
> +#define ORC_REG_BP 4
> +#define ORC_REG_SP 5
> +#define ORC_REG_R10 6
> +#define ORC_REG_R13 7
> +#define ORC_REG_BP_INDIRECT 8
> +#define ORC_REG_SP_INDIRECT 9
> +#define ORC_REG_MAX 15
> +
> +/*
> + * ORC_TYPE_CALL: Indicates that sp_reg+sp_offset resolves to PREV_SP (the
> + * caller's SP right before it made the call). Used for all callable
> + * functions, i.e. all C code and all callable asm functions.
> + *
> + * ORC_TYPE_REGS: Used in entry code to indicate that sp_reg+sp_offset points
> + * to a fully populated pt_regs from a syscall, interrupt, or exception.
> + *
> + * ORC_TYPE_REGS_IRET: Used in entry code to indicate that sp_reg+sp_offset
> + * points to the iret return frame.
> + *
> + * The UNWIND_HINT macros are used only for the unwind_hint struct. They
> + * aren't used in struct orc_entry due to size and complexity constraints.
> + * Objtool converts them to real types when it converts the hints to orc
> + * entries.
> + */
> +#define ORC_TYPE_CALL 0
> +#define ORC_TYPE_REGS 1
> +#define ORC_TYPE_REGS_IRET 2
> +#define UNWIND_HINT_TYPE_SAVE 3
> +#define UNWIND_HINT_TYPE_RESTORE 4
> +
> +#ifndef __ASSEMBLY__
> +/*
> + * This struct is more or less a vastly simplified version of the DWARF Call
> + * Frame Information standard. It contains only the necessary parts of DWARF
> + * CFI, simplified for ease of access by the in-kernel unwinder. It tells the
> + * unwinder how to find the previous SP and BP (and sometimes entry regs) on
> + * the stack for a given code address. Each instance of the struct corresponds
> + * to one or more code locations.
> + */
> +struct orc_entry {
> + s16 sp_offset;
> + s16 bp_offset;
> + unsigned sp_reg:4;
> + unsigned bp_reg:4;
> + unsigned type:2;
> + unsigned end:1;
> +} __packed;
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* _ORC_TYPES_H */
Since ORC is now treated as arch-specific, and not yet implemented for
arm64, can this header file just be (basically) empty for now?
--
Josh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-22 20:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 12:23 [RFC v4 00/18] objtool: Add support for arm64 Raphael Gault
2019-08-16 12:23 ` [RFC v4 01/18] objtool: Add abstraction for computation of symbols offsets Raphael Gault
2019-08-22 16:30 ` Julien
2019-08-22 19:57 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 02/18] objtool: orc: Refactor ORC API for other architectures to implement Raphael Gault
2019-08-22 19:59 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 03/18] objtool: Move registers and control flow to arch-dependent code Raphael Gault
2019-08-22 20:00 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 04/18] objtool: arm64: Add required implementation for supporting the aarch64 architecture in objtool Raphael Gault
2019-08-22 20:00 ` Josh Poimboeuf [this message]
2019-08-16 12:23 ` [RFC v4 05/18] objtool: special: Adapt special section handling Raphael Gault
2019-08-22 20:02 ` Josh Poimboeuf
2019-08-22 20:18 ` Julien
2019-08-16 12:23 ` [RFC v4 06/18] objtool: arm64: Adapt the stack frame checks for arm architecture Raphael Gault
2019-08-22 20:03 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 07/18] objtool: Introduce INSN_UNKNOWN type Raphael Gault
2019-08-22 20:04 ` Josh Poimboeuf
2019-08-22 20:45 ` Julien
2019-08-22 21:51 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 08/18] objtool: Refactor switch-tables code to support other architectures Raphael Gault
2019-08-22 20:04 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 09/18] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Raphael Gault
2019-08-22 20:05 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 10/18] objtool: arm64: Implement functions to add switch tables alternatives Raphael Gault
2019-08-23 16:35 ` Julien
2019-08-16 12:23 ` [RFC v4 11/18] arm64: alternative: Mark .altinstr_replacement as containing executable instructions Raphael Gault
2019-08-16 12:23 ` [RFC v4 12/18] arm64: assembler: Add macro to annotate asm function having non standard stack-frame Raphael Gault
2019-08-22 20:10 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 13/18] arm64: sleep: Prevent stack frame warnings from objtool Raphael Gault
2019-08-22 20:16 ` Josh Poimboeuf
2019-08-16 12:23 ` [RFC v4 14/18] arm64: kvm: Annotate non-standard stack frame functions Raphael Gault
2019-08-16 12:24 ` [RFC v4 15/18] arm64: kernel: Add exception on kuser32 to prevent stack analysis Raphael Gault
2019-08-16 12:24 ` [RFC v4 16/18] arm64: crypto: Add exceptions for crypto object " Raphael Gault
2019-08-22 20:19 ` Josh Poimboeuf
2019-08-16 12:24 ` [RFC v4 17/18] arm64: kernel: Annotate non-standard stack frame functions Raphael Gault
2019-08-16 12:24 ` [RFC v4 18/18] objtool: arm64: Enable stack validation for arm64 Raphael Gault
2019-08-22 19:56 ` [RFC v4 00/18] objtool: Add support " Josh Poimboeuf
2019-08-23 12:00 ` Raphael Gault
2019-10-14 8:37 ` Julien Thierry
2019-10-14 13:27 ` Raphaël Gault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190822200051.in6qxtv23le6jrtf@treble \
--to=jpoimboe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=raph.gault+kdev@gmail.com \
--cc=raphael.gault@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).