From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932425AbdK0Rek (ORCPT ); Mon, 27 Nov 2017 12:34:40 -0500 Received: from mout.gmx.net ([212.227.17.20]:60012 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753718AbdK0Reh (ORCPT ); Mon, 27 Nov 2017 12:34:37 -0500 From: Sven Joachim To: Josh Poimboeuf Cc: Mikulas Patocka , Andy Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Jiri Slaby , Peter Zijlstra , Thomas Gleixner , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar Subject: Re: [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace References: <20171107175539.zkbzaapmok2b7hbb@treble> Date: Mon, 27 Nov 2017 18:32:48 +0100 In-Reply-To: <20171107175539.zkbzaapmok2b7hbb@treble> (Josh Poimboeuf's message of "Tue, 7 Nov 2017 11:55:39 -0600") Message-ID: <87r2sjzkxr.fsf@turtle.gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:QtPfXawEdQVlaefCuorozj2o7PD697Is6LhN4FModWaJdui86S8 V4eDDdZ+3iajRr8mMfsdmLfgg7Nj+p8+38ZL7GjCKMANszZRpIitLA+To/tNK7QUCLEt7xy u/6qmjtxgcqhiKE3rq2GvddhadXwlYltBKYoxWaUC9+ZK/83r+oA65VejS00rT/6AkXDPWP 5uY6ertmimc3Jy+CFB9Dg== X-UI-Out-Filterresults: notjunk:1;V01:K0:sem65VGSibc=:bUaOiabzixqIsUeJ6SCzeN g43ZWSmqZk/tSpa9ft9tw2DNTKzoTiOMFEyD2QLfk6hTQqIhaIbS/ZweFN3dzcHa1Y63KfFET 5asfyYCHpASVMCqOrFkQtLzOZ5oDXXhzk5CB0FLcevSPMj1aiq9hti4LLhdcY6QdNgJzmqPWH x8/qrLAJ7c4nvUb1BT1JopGS/A2nP7Bq8420tO6+0bW49ipdwsdY9GsoBtDIHmRAUSZWw/Ixu Vp5OT5mafzMlWsRasxEzZ1oz0Bk/ROSlmntqEKtUQWcp+jxLw+TSGaRxgN5W+LfKV00i6lxi/ 3MeU0qhHLaQiYNbWyWtHhUQeDuB44lfBB2hYKtyCc2LgKCTq1T7U4zW7DvcjkkJbvSGY7Tc0X s0tiRRKNQKpY/O0H/1qYsMT+ADRn2Wv+k1qD/A2HjS3ay1A0ZF+cnwFu8LoPBOb0aKo9JqPbF ung5s61cODtmIziwdggTY1ATTgVvEySyGPo6DGDNBlD30/rfBnD7WD1Y0sALv2pBYCUaXVsE7 9VbcAPnAOPkLimYm9aLUu777LWe07jiLv0o2KVe4VUTEwD91jhksaBNDZE+nWb0Un2IueuGdI m9IgHZb7Vv0ZHkhpyc6qdgUf7FDj+20mLPXmPbksnbelKjUyYiBML1Q7hMx54htJqY4DAInod 5ZYMfcX+m9JQpqRXICCAbvBdzBs/5sGuBolEtyW9sOyv3JkVRZ+kBxmVg3MGmTYicU+YmiTkk 7unPM1nPNs/EFxy4069ofsN/20zxCeyBEI8q6ANoWaZSq+BGCBRubYbWSOQTDlqIxkUNaRX7p ARnVXoXZi2z3aEl2CD8lMVFbreidYBEzr+Hx63LOLhXhym7laM= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-11-07 11:55 -0600, Josh Poimboeuf wrote: > [ Adding Ingo to cc because I believe it was his suggestion to hide the > guess unwinder behind CONFIG_EXPERT. ] > > On Mon, Nov 06, 2017 at 06:27:53PM -0500, Mikulas Patocka wrote: >> This patch fixes building of 64-bit kernel on 32-bit userspace (I tested >> it on RHEL-6-i686 and Debian-Sid-x32). > > Thanks, I'll review the patch. Any news on that? After upgrading to 4.15-rc1 and running "make oldconfig" I found out that the kernel would no longer build unless I selected CONFIG_UNWINDER_FRAME_POINTER=y. ,---- | $ uname -m | x86_64 | $ dpkg --print-architecture | i386 `---- >> There are still some more bugs - when building 64-bit kernel on 32-bit >> Debian 7 distribution, objtool corrupts object files so that the linker >> doesn't recognize them (ld doesn't recognize the format of the file at all >> and gold prints a lot of errors). > > Hm, we should figure out what's going on there... > >> Another problem - when building 32-bit kernel, why do you force frame >> pointers on and why did you hide CONFIG_GUESS_UNWINDER behind >> CONFIG_EXPERT? Frame pointers increase code size and register pressure, >> most users don't need precise stacktraces, so CONFIG_GUESS_UNWINDER should >> be default for non-expert users just like it was before. >> >> Is there some technical reason why do you want to avoid >> CONFIG_GUESS_UNWINDER? > > The technical reason for avoiding the guess unwinder is that it's > sketchy: it gives false positive results. Not only for oopses, but for > all the other users of the unwinder: /proc//stack, perf, lockdep, > etc. So it's a correctness issue. > > I agree with you that the frame pointer unwinder has drawbacks, but if > somebody cares about those drawbacks, I would consider that person an > "expert" ;-) Cheers, Sven