linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vasily Gorbik <gor@linux.ibm.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Miroslav Benes <mbenes@suse.cz>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	Julien Thierry <jthierry@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/2] objtool and cross compilation
Date: Wed, 30 Sep 2020 11:58:24 +0200	[thread overview]
Message-ID: <cover.thread-e6a24b.your-ad-here.call-01601459756-ext-4914@work.hours> (raw)

This is based on v5.9-rc7, before "other architectures support" patches
starting pouring in.

Currently objtool seems to be the only tool from build tools needed
which breaks x86 cross compilation on big endian systems.

But besides x86 cross compilation, endianness awareness is also needed
for big endian architectures objtool support in general.

We have working prototype of objtool support and orc unwinder for s390
made originally by Martin Schwidefsky. I'm trying to bring it in shape
again and refactor to share more code with "generic" part.

But first things first. These 2 patches point to endianness problems
which should be addressed. And I'd be glad to get any ideas how to make
them less ugly.

New "other architectures support" patches currently move only some
problematic parts into x86 arch specific folder. But the main problem
is that arch/x86/lib/insn.c and arch/x86/include/asm/insn.h are shared
across the kernel source and the tools, and there is no common way to
address endianness problems.

Since big endian stuff is only needed for the objtool and not for the
kernel I can try to hide alternative big endian definitions in tools
only header which is included only if __KERNEL__ is not defined. But
that kind of defeats the idea of sharing those files 1 to 1 with tools.

Thoughts? Any suggestions are welcome.

Martin Schwidefsky (1):
  objtool: x86 instruction decoder and big endian cross compiles

Vasily Gorbik (1):
  objtool: fix x86 orc generation on big endian cross compiles

 arch/x86/include/asm/insn.h            | 43 ++++++++++++
 arch/x86/include/asm/orc_types.h       | 24 +++++++
 arch/x86/lib/insn.c                    | 95 +++++++++++---------------
 tools/arch/x86/include/asm/insn.h      | 43 ++++++++++++
 tools/arch/x86/include/asm/orc_types.h | 24 +++++++
 tools/arch/x86/lib/insn.c              | 95 +++++++++++---------------
 tools/objtool/check.c                  |  4 +-
 tools/objtool/elf.c                    | 34 +++++----
 tools/objtool/orc_dump.c               |  4 +-
 tools/objtool/orc_gen.c                |  2 +
 tools/objtool/special.c                |  4 +-
 11 files changed, 243 insertions(+), 129 deletions(-)

-- 
⣿⣿⣿⣿⢋⡀⣀⠹⣿⣿⣿⣿
⣿⣿⣿⣿⠠⣶⡦⠀⣿⣿⣿⣿
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿

             reply	other threads:[~2020-09-30  9:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  9:58 Vasily Gorbik [this message]
2020-09-30  9:58 ` [RFC PATCH 1/2] objtool: x86 instruction decoder and big endian cross compiles Vasily Gorbik
2020-09-30  9:58 ` [RFC PATCH 2/2] objtool: fix x86 orc generation on " Vasily Gorbik
2020-09-30 10:12 ` [RFC PATCH 0/2] objtool and cross compilation Peter Zijlstra
2020-09-30 12:24   ` [RFC PATCH v2 " Vasily Gorbik
2020-09-30 12:24     ` [RFC PATCH v2 1/2] objtool: x86 instruction decoder and big endian cross compiles Vasily Gorbik
2020-09-30 15:19       ` Josh Poimboeuf
2020-09-30 12:24     ` [RFC PATCH v2 2/2] objtool: fix x86 orc generation on " Vasily Gorbik
2020-09-30 13:06       ` David Laight

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=cover.thread-e6a24b.your-ad-here.call-01601459756-ext-4914@work.hours \
    --to=gor@linux.ibm.com \
    --cc=alexandre.chartre@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=jthierry@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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).