linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Raphael Gault <raphael.gault@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: jpoimboe@redhat.com, peterz@infradead.org,
	catalin.marinas@arm.com, will.deacon@arm.com,
	julien.thierry@arm.com, Raphael Gault <raphael.gault@arm.com>
Subject: [PATCH 0/6] objtool: Add support for Arm64
Date: Tue,  9 Apr 2019 14:52:37 +0100	[thread overview]
Message-ID: <20190409135243.12424-1-raphael.gault@arm.com> (raw)

Hi,

As of now, objtool only supports the x86_64 architecture but the
groundwork has already been done in order to add support for other
architecture without too much effort.

This series of patches adds support for the arm64 architecture
based on the Armv8.5 Architecture Reference Manual.

* Patch 1 adapts the existing code to be able to add support for other
  architecture.
* Patch 2 provide implementation of the required function for the arm64
  architecture.
* Patch 3 adapts the checking of the stack state for the arm64
  architecture.
* Patch 4 & 5 fix some warning objtool raised in some particular
  functions of ~/arch/arm64/kernel/sleep.S. Patch 4 add a macro to
  signal that some function should be ignored by objtool. 
* Patch 6 enables stack validation for arm64.

Theses patches should provide support for the main cases and behaviour.
However a few corner cases are not yet handled by objtool:

* In the `~/arch/arm64/crypto/` directory, I noticed that some plain
  data are sometimes stored in the `.text` section causing objtool to mistake
  this for instructions and trying (and failing) to interprete them.  If someone
  could explain to me why we store data directly in the .text section I would
  appreciate it.

* In the support for arm32 architecture such as in `~/arch/arm64/kernel/kuser32.S`
  some A32 instructions are used but such instructions are not understood by
  objtool causing a warning.

I also have a few unclear points I would like to bring to your
attention:

* For x86_64, when looking for a symbol relocation with explicit
  addend, objtool systematically adds a +4 offset to the addend.
  I don't understand why even if I have a feeling it is related
  to the type of relacation.

* I currently don't have a clear understanding about how switch-tables
  are generated on arm64 and how to retrieve them (based on relocations).

Please provide me with any feedback and comments as well on the content
than the style of these patches.

Thanks,

Raphael

->

Raphael Gault (6):
  objtool: Refactor code to make it more suitable for multiple
    architecture support
  objtool: arm64: Add required implementation for supporting the aarch64
    architecture in objtool.
  objtool: arm64: Adapt the stack frame checks and the section analysis
    for the arm architecture
  arm64: assembler: Add macro to annotate asm function having non
    standard stack-frame.
  arm64: sleep: Add stack frame setup for __cpu_supsend_enter
  objtool: arm64: Enable stack validation for arm64

 arch/arm64/Kconfig                            |    1 +
 arch/arm64/include/asm/assembler.h            |   18 +
 arch/arm64/kernel/sleep.S                     |    4 +
 tools/objtool/Build                           |    1 -
 tools/objtool/arch.h                          |   11 +
 tools/objtool/arch/arm64/Build                |    6 +
 tools/objtool/arch/arm64/bit_operations.c     |   65 +
 tools/objtool/arch/arm64/decode.c             | 2870 +++++++++++++++++
 .../objtool/arch/arm64/include/arch_special.h |   44 +
 .../arch/arm64/include/asm/orc_types.h        |  109 +
 .../arch/arm64/include/bit_operations.h       |   22 +
 tools/objtool/arch/arm64/include/cfi.h        |   76 +
 .../objtool/arch/arm64/include/insn_decode.h  |  219 ++
 tools/objtool/arch/arm64/orc_gen.c            |   40 +
 tools/objtool/arch/x86/Build                  |    1 +
 tools/objtool/arch/x86/decode.c               |  111 +
 tools/objtool/arch/x86/include/arch_special.h |   35 +
 tools/objtool/{ => arch/x86/include}/cfi.h    |    0
 tools/objtool/{ => arch/x86}/orc_gen.c        |   10 +-
 tools/objtool/check.c                         |  209 +-
 tools/objtool/check.h                         |    1 +
 tools/objtool/elf.c                           |    3 +-
 tools/objtool/orc.h                           |    4 +-
 tools/objtool/special.c                       |   18 +-
 24 files changed, 3740 insertions(+), 138 deletions(-)
 create mode 100644 tools/objtool/arch/arm64/Build
 create mode 100644 tools/objtool/arch/arm64/bit_operations.c
 create mode 100644 tools/objtool/arch/arm64/decode.c
 create mode 100644 tools/objtool/arch/arm64/include/arch_special.h
 create mode 100644 tools/objtool/arch/arm64/include/asm/orc_types.h
 create mode 100644 tools/objtool/arch/arm64/include/bit_operations.h
 create mode 100644 tools/objtool/arch/arm64/include/cfi.h
 create mode 100644 tools/objtool/arch/arm64/include/insn_decode.h
 create mode 100644 tools/objtool/arch/arm64/orc_gen.c
 create mode 100644 tools/objtool/arch/x86/include/arch_special.h
 rename tools/objtool/{ => arch/x86/include}/cfi.h (100%)
 rename tools/objtool/{ => arch/x86}/orc_gen.c (96%)

-- 
2.17.1


             reply	other threads:[~2019-04-09 13:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 13:52 Raphael Gault [this message]
2019-04-09 13:52 ` [RFC 1/6] objtool: Refactor code to make it more suitable for multiple architecture support Raphael Gault
2019-04-23 20:13   ` Josh Poimboeuf
2019-04-24 16:11     ` Raphael Gault
2019-04-24 16:17       ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 2/6] objtool: arm64: Add required implementation for supporting the aarch64 architecture in objtool Raphael Gault
2019-04-09 16:20   ` Peter Zijlstra
2019-04-23 20:18   ` Josh Poimboeuf
2019-04-24 16:16     ` Raphael Gault
2019-04-24 16:23       ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 3/6] objtool: arm64: Adapt the stack frame checks and the section analysis for the arm architecture Raphael Gault
2019-04-09 16:12   ` Peter Zijlstra
2019-04-09 16:24     ` Mark Rutland
2019-04-09 16:27       ` Julien Thierry
2019-04-09 16:33         ` Raphaël Gault
2019-04-23 20:36   ` Josh Poimboeuf
2019-04-24 16:32     ` Raphael Gault
2019-04-24 16:56       ` Josh Poimboeuf
2019-04-25  8:12         ` Raphael Gault
2019-04-25  8:33           ` Peter Zijlstra
2019-04-25 16:25           ` Josh Poimboeuf
2019-04-30 12:20             ` Raphael Gault
2019-05-01 15:09               ` Raphael Gault
2019-04-24 10:36   ` Julien Thierry
2019-04-09 13:52 ` [RFC 4/6] arm64: assembler: Add macro to annotate asm function having non standard stack-frame Raphael Gault
2019-04-24 10:44   ` Julien Thierry
2019-04-09 13:52 ` [RFC 5/6] arm64: sleep: Add stack frame setup for __cpu_supsend_enter Raphael Gault
2019-04-23 20:37   ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 6/6] objtool: arm64: Enable stack validation for arm64 Raphael Gault
2019-04-09 14:57 ` [PATCH 0/6] objtool: Add support for Arm64 Josh Poimboeuf
2019-04-09 17:43 ` Ard Biesheuvel
2019-04-10  3:37   ` Josh Poimboeuf
2019-04-10  7:20     ` Julien Thierry
2019-04-23 21:09 ` Josh Poimboeuf
2019-04-24 16:08   ` Raphael Gault
2019-04-24 16:14     ` Josh Poimboeuf

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=20190409135243.12424-1-raphael.gault@arm.com \
    --to=raphael.gault@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=jpoimboe@redhat.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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).