Re: RFC: vdso build-id standard location

[Andy Lutomirski <luto at amacapital dot net>]

On Tue, Jun 24, 2014 at 7:17 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 21 Jun 2014 00:13:57 +0200, Andy Lutomirski wrote:
>> This patch will cause 'make vdso_install' to install build-id symlinks
>> to /lib/modules/KERNEL_VERSION/vdso/.build-id
>>
>> The idea is that gdb on Linux platforms could change its default
>> build-id search path to include that directory and therefore find vdso
>> debug info for home-built kernels instead of just for Fedora-style
>> kernel RPMs.
>>
>> Is this reasonable?  Is it something that can/should be easily added to gdb?
>
> Since
>         Handle VDSO section headers past end of page
>         https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5979d6b69b20a8355ea94b75fad97415fce4788c
> I do not think there is a need for splitting debug info out of vDSOs, vDSO
> DWARF could remain in the in-memory mapped vDSO and there is no need for
> on-disk counterpart file then.  BTW I do not have it tested it works this way.

That debug info is 65k on my build.  I don't think that should end up
in every core file, in unpageable kernel memory, and mapped into every
process.

>
> I do not remember if the debug info splitting is done by upstream kernel
> install scripts or by the Fedora rpm debug info splitting scripts.
> If it is done by upstream kernel scripts it should be removed and that's all.

Fedora.

For a bit more background, the vdso files on disk aren't what's loaded
into each process.  The kernel contains a stripped copy, and that
stripped copy is loaded.  The vdso still works even if those .so files
aren't on the disk at all.

In Linux 3.16, the vdso accesses some data shared with the kernel
using pc-relative relocations.  This is currently done by having the
vdso linker script define some symbols that live in the pages right
after the PT_LOAD segment.  That's why I started stripping off the
vdso section headers: those section headers are at the end of the .so
file, which means that they's after (and outside of!) the PT_LOAD
segment.  If I get unlucky, those headers go into the next page, and
they overlap the kernel shared data.  Boom.  So I removed them,
because I assumed that nothing would use them.

As far as I can see, there are only three ways to do this:

1. vvar data after vdso text.  This is what I'm doing.  I have patches
that hack the vdso image so that the section headers are actually *in*
the PT_LOAD segment.  It works, but it's fragile.

2. vvar data before vdso text.  IMO this is ugly, but it's probably
more reliable, and I might switch to doing that.  Note that 3.15
32-bit builds work that way.

3. vvar data in its own segment after the vdso ELF headers but before
the section headers.  I think this is unworkable in the kernel: it
will require putting the vvar vma in the middle of the vdso vma, and
that will get very messy.

I'm not sure yet what I'm going to do about this.

--Andy