From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <dvlasenk@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>, Jiri Slaby <jslaby@suse.cz>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace
Date: Tue, 7 Nov 2017 11:55:39 -0600 [thread overview]
Message-ID: <20171107175539.zkbzaapmok2b7hbb@treble> (raw)
In-Reply-To: <alpine.LRH.2.02.1711061812460.18820@file01.intranet.prod.int.rdu2.redhat.com>
[ 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.
> 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/<pid>/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" ;-)
--
Josh
next prev parent reply other threads:[~2017-11-07 17:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 23:27 [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace Mikulas Patocka
2017-11-07 17:55 ` Josh Poimboeuf [this message]
2017-11-07 21:25 ` Mikulas Patocka
2017-11-08 8:07 ` Peter Zijlstra
2017-11-27 17:32 ` Sven Joachim
2017-11-27 19:27 ` Josh Poimboeuf
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=20171107175539.zkbzaapmok2b7hbb@treble \
--to=jpoimboe@redhat.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mpatocka@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.