Re: [PATCH v2 5/5] x86,vdso: Create .build-id links for unstripped vdso files

[Andy Lutomirski]

On Thu, Apr 25, 2019 at 4:42 AM Masahiro Yamada
<yamada.masahiro@xxxxxxxxxxxxx> wrote:
>
> Hi Andy,
>
> On Sat, Jun 21, 2014 at 4:23 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> >
> > With this change, doing 'make vdso_install' and telling gdb:
> >
> > set debug-file-directory /lib/modules/KVER/vdso
> >
> > will enable vdso debugging with symbols.  This is useful for
> > testing, but kernel RPM builds will probably want to manually delete
> > these symlinks or otherwise do something sensible when they strip
> > the vdso/*.so files.
> >
> > If ld does not support --build-id, then the symlinks will not be
> > created.
> >
> > Note that kernel packagers that use vdso_install may need to adjust
> > their packaging scripts to accomdate this change.  For example,
> > Fedora's scripts create build-id symlinks themselves in a different
> > location, so the spec should probably be updated to remove the
> > symlinks created by make vdso_install.
> >
> > Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> > ---
>
> I was looking into this, but
> I am not familiar enough with this area.
>
>
> Could you tell me how it works?
>
>
> I use Ubuntu 18.04 LTS.
> Luckily, it has build-id symlinks by default,
> so I should be able to test it easily.
>
>
>
> masahiro@pug:~$ uname -r
> 4.15.0-47-generic
> masahiro@pug:~$ cd /lib/modules/4.15.0-47-generic/vdso/
> masahiro@pug:/lib/modules/4.15.0-47-generic/vdso$ file vdso64.so
> vdso64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked,
> BuildID[sha1]=d742540fb9ded5c3650dbe9ae20c0f39e386464c, with
> debug_info, not stripped
> masahiro@pug:/lib/modules/4.15.0-47-generic/vdso$ ls -l
> .build-id/d7/42540fb9ded5c3650dbe9ae20c0f39e386464c.debug
> lrwxrwxrwx 1 root root 15 Mar 13 13:37
> .build-id/d7/42540fb9ded5c3650dbe9ae20c0f39e386464c.debug ->
> ../../vdso64.so
>
>
> I dumped the vdso embedded in the kernel,
> and I confirmed its build-id matches
> to the one of unstripped vdso.
>
>
> So, I expect the vdso with symbol info will be automatically loaded
> by setting debug-file-directory to /lib/modules/4.15.0-47-generic/vdso.
> Am I right?
>
> If it works as expected, how should it look like?
>
> I started gdb like this:
>
> $ gdb date
>
> Then, I did:
>
> (gdb) set debug-file-directory
> /usr/lib/debug:/lib/modules/4.15.0-47-generic/vdso
> (gdb) show debug-file-directory
> The directory where separate debug symbols are searched for is
> "/usr/lib/debug:/lib/modules/4.15.0-47-generic/vdso".
> (gdb) run
>
>
> The list of shared library looks like follows:
>
>
> (gdb) info sharedlibrary
> From                To                  Syms Read   Shared Object Library
> 0x00007ffff7dd5f10  0x00007ffff7df4b20  Yes         /lib64/ld-linux-x86-64.so.2
> 0x00007ffff7a052d0  0x00007ffff7b7dc3c  Yes
> /lib/x86_64-linux-gnu/libc.so.6
>                                         No          linux-vdso.so.1
>
>
>
> The first two shared objects shows "Yes" because debug info
> is available under /usr/lib/debug/lib/x86_64-linux-gnu/
> and associated by .gnu_debuglink.
>
>
> linux-vdso.so.1 shows "No".
> Does it mean no symbol was included ?
>

It's been a long time since I've looked at this, and I don't remember
all the details.  I think your best bet may be to run gdb under strace
and to try to figure out what it's doing.