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;
Date:   Wed, 30 Sep 2020 14:24:16 +0200
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 v2 0/2] objtool and cross compilation
Message-ID: <cover.thread-ca645c.your-ad-here.call-01601468251-ext-3723@work.hours>
References: <20200930101251.GX2628@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200930101251.GX2628@hirez.programming.kicks-ass.net>
Precedence: bulk

rfc v1 - rfc v2:
 - rebased onto tip/objtool/core
 - reformatted couple of lines

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            | 42 ++++++++++++
 arch/x86/include/asm/orc_types.h       | 24 +++++++
 arch/x86/lib/insn.c                    | 95 +++++++++++---------------
 tools/arch/x86/include/asm/insn.h      | 42 ++++++++++++
 tools/arch/x86/include/asm/orc_types.h | 24 +++++++
 tools/arch/x86/lib/insn.c              | 95 +++++++++++---------------
 tools/objtool/arch/x86/special.c       |  2 +-
 tools/objtool/check.c                  |  4 +-
 tools/objtool/elf.c                    | 34 +++++----
 tools/objtool/orc_dump.c               |  4 +-
 tools/objtool/orc_gen.c                |  2 +
 11 files changed, 240 insertions(+), 128 deletions(-)

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