[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP=VYLrzMP23B9NVnu4N3NYsoU+ai1K9HpAE_eXQzXESUUZ-Lg@mail.gmail.com>
Date: Thu, 29 May 2014 15:17:54 -0400
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: mingo@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
luto@...capital.net, LKML <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>, hpa@...ux.intel.com
Cc: linux-tip-commits@...r.kernel.org,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>
Subject: Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in
build-time C
On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski
<tipbot@...or.com> wrote:
> Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829
> Gitweb: http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829
> Author: Andy Lutomirski <luto@...capital.net>
> AuthorDate: Mon, 5 May 2014 12:19:34 -0700
> Committer: H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Mon, 5 May 2014 13:18:51 -0700
>
> x86, vdso: Reimplement vdso.so preparation in build-time C
Just a heads up in case it hasn't been mentioned already;
the x86 builds in linux-next which IIRC are done as cross
compile on a powerpc box are failing as follows:
VDSO2C arch/x86/vdso/vdso-image-64.c
/bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c
arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c
make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139
http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/
Paul.
--
>
> Currently, vdso.so files are prepared and analyzed by a combination
> of objcopy, nm, some linker script tricks, and some simple ELF
> parsers in the kernel. Replace all of that with plain C code that
> runs at build time.
>
> All five vdso images now generate .c files that are compiled and
> linked in to the kernel image.
>
> This should cause only one userspace-visible change: the loaded vDSO
> images are stripped more heavily than they used to be. Everything
> outside the loadable segment is dropped. In particular, this causes
> the section table and section name strings to be missing. This
> should be fine: real dynamic loaders don't load or inspect these
> tables anyway. The result is roughly equivalent to eu-strip's
> --strip-sections option.
>
> The purpose of this change is to enable the vvar and hpet mappings
> to be moved to the page following the vDSO load segment. Currently,
> it is possible for the section table to extend into the page after
> the load segment, so, if we map it, it risks overlapping the vvar or
> hpet page. This happens whenever the load segment is just under a
> multiple of PAGE_SIZE.
>
> The only real subtlety here is that the old code had a C file with
> inline assembler that did 'call VDSO32_vsyscall' and a linker script
> that defined 'VDSO32_vsyscall = __kernel_vsyscall'. This most
> likely worked by accident: the linker script entry defines a symbol
> associated with an address as opposed to an alias for the real
> dynamic symbol __kernel_vsyscall. That caused ld to relocate the
> reference at link time instead of leaving an interposable dynamic
> relocation. Since the VDSO32_vsyscall hack is no longer needed, I
> now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it
> work. vdso2c will generate an error and abort the build if the
> resulting image contains any dynamic relocations, so we won't
> silently generate bad vdso images.
>
> (Dynamic relocations are a problem because nothing will even attempt
> to relocate the vdso.)
>
> Signed-off-by: Andy Lutomirski <luto@...capital.net>
> Link: http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.luto@amacapital.net
> Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> ---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists