Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Matt Helsley <mhelsley@vmware.com>
To:     <linux-kernel@vger.kernel.org>
CC:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Julien Thierry <jthierry@redhat.com>,
        Miroslav Benes <mbenes@suse.cz>,
        Steven Rostedt <rostedt@goodmis.org>,
        Matt Helsley <mhelsley@vmware.com>
Subject: [PATCH 0/3] Enable objtool multiarch build
Date:   Tue, 19 May 2020 13:55:30 -0700
Message-ID: <cover.1589913349.git.mhelsley@vmware.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Content-Type:   text/plain; charset=US-ASCII
Received-SPF: None (EX13-EDG-OU-002.vmware.com: mhelsley@vmware.com does not
 designate permitted sender hosts)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

As a necessary first step to adding new architecture and subcommand
support to objtool enabling building of objtool for more than the x86
architecture.

Some folks have been working on enabling objtool checking functionality
for arm64. Rather than repeat that work here this minimal set does not
port the existing commands but replaces them with weak, not-implemented
versions which exit with status 127. On x86 the check and orc
subcommands will still build and operate correctly while on other
architectures the commands will exit with status 127. This allows future
changes to port the check command to arm64 or add new subcommands
such as mcount to replace the separate recordmcount tool.

Since the series does not add support for stack validation or checking
to any new architectures there's no reason to make KConfig or Makefile
changes which would normally be used to test this. So I've been forcing
builds of objtool with:

make O=build-foo ARCH=foo CROSS_COMPILE=foo-linux-gnu- defconfig
make O=build-foo ARCH=foo CROSS_COMPILE=foo-linux-gnu- tools/objtool

And running the resulting binary to verify that it shows all objtoo
subcommands are supported on x86 and unsupported on other archs.

Changes since RFC[1]:
 - Removed the arch/missing pattern and put everything in weak.c
	(Julien Thierry and Josh Poimboeuf)
 - Kept arch.h, special, etc. in the top level objtool dir (Julien)
 - Dropped the patch reporting which subcommands are missing in --help
	output
 - Postponed the rela patch
	Josh asked to rename a bunch of these variables and suggested
	an untested improvement. Since they're necessary for
	recordmcount but not the current arch built support we can drop
	them from this set.
 - Misc: Removed else (Josh) and updated the commit messages (Julien)
 - Cleaned up includes
	Moved the prototypes for the command entry functions and other
	functions that weak symbols need to be consistent with into
	objtool.h. (Josh)

Tested with cross-compilation for sparc, arm64, s390, and powerpc

[1] https://lore.kernel.org/lkml/cover.1588888003.git.mhelsley@vmware.com/

Matt Helsley (3):
  objtool: Exit successfully when requesting help
  objtool: Move struct objtool_file into arch-independent header
  objtool: Enable compilation of objtool for all architectures

 tools/objtool/Build           | 13 +++++++++----
 tools/objtool/Makefile        | 11 ++++++++++-
 tools/objtool/arch.h          |  4 +++-
 tools/objtool/builtin-check.c |  2 +-
 tools/objtool/builtin-orc.c   |  3 +--
 tools/objtool/check.c         |  4 ++--
 tools/objtool/check.h         | 12 ------------
 tools/objtool/objtool.c       |  4 +++-
 tools/objtool/objtool.h       | 34 ++++++++++++++++++++++++++++++++++
 tools/objtool/orc.h           | 18 ------------------
 tools/objtool/orc_dump.c      |  3 ++-
 tools/objtool/orc_gen.c       |  1 -
 tools/objtool/weak.c          | 35 +++++++++++++++++++++++++++++++++++
 13 files changed, 100 insertions(+), 44 deletions(-)
 create mode 100644 tools/objtool/objtool.h
 delete mode 100644 tools/objtool/orc.h
 create mode 100644 tools/objtool/weak.c


base-commit: bba413deb1065f1291cb1f366247513f11215520
-- 
2.20.1