[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2205161145070.30905@file01.intranet.prod.int.rdu2.redhat.com>
Date: Mon, 16 May 2022 11:56:21 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] objtool: fix objtool regression on x32 systems
On Mon, 16 May 2022, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 11:06:36AM -0400, Mikulas Patocka wrote:
> > The patch 4abff6d48dbc ("objtool: Fix code relocs vs weak symbols") makes
> > the kernel unbootable. The patch c087c6e7b551 ("objtool: Fix type of
> > reloc::addend") attempts to fix it by replacing 'int' with 'long'.
> >
> > However, we may be running on a system with x32 ABI and 'long' on x32 is
> > 32-bit, thus the patch c087c6e7b551 doesn't really change anything and we
> > still end up with miscompiled kernel. This patch replaces 'long' with
> > 'long long', so that the 64-bit kernel is correctly compiled on a x32
> > system.
>
> Hurmph.. you're building a 64bit kernel on a x32 hosted machine? And
> this is the *only* thing that goes sideways?
I use the x32 ABI (that is 64-bit mode with addresses truncated to
32-bit). gcc compiled for the x32 ABI is about 5% to 10% faster than gcc
compiled for the amd64 ABI. I installed the x32 gcc from Debian Ports.
> I suspect quite a bit of objtool assumes LP64 and won't quite work right
> on ILP32 and we've just been lucky so far.
With this patch, the compiled kernel works. With kernels 5.17 or older, it
also works. I bisected it and the breakage is caused by the commit
4abff6d48dbc.
Mikulas
Powered by blists - more mailing lists