Messages in this thread | | | From | Sven Joachim <> | Subject | Re: [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace | Date | Mon, 27 Nov 2017 18:32:48 +0100 |
| |
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/<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" ;-)
Cheers, Sven
| |