warning: Could not load shared library symbols for linux-vdso.so.1.

[Pedro Alves]

On 08/12/2016 11:28 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Is there an easy way to check whether we're in the vdso prelinked
>> situation just from doing some address comparisions?  I feel like that
>> should be possible, but I didn't think it through.  It is is indeed
>> possible, we could alwayy skip the /proc/pid/maps parsing entirely
>> even against live processes, on modern kernels.
> 
> I don't know either.  However, looks vDSO prelink is done only on x86
> and was already removed from kernel in 2014, as far as I can see.  The
> base address of vDSO in kernel is VDSO_PRELINK, which is hard-coded.  I
> am not sure we can rely on this hard-coded constant.

I tried to come up with some clean way to detect this, and failed.

This made me have second thoughts on the approach, since there's a remote
chance that we'll hide the wrong DSO, on older kernels.

I think I found an alternative fix.  

The idea is simply to read the vDSO bfd out of memory anyway even
when we weren't able to find its size from the mappings.  When 
elf_bfd_from_remote_memory is passed '0' for size, it figures
out the size of the elf in memory from the elf structure.  If we use
that as another source for the vdso address range, then
svr4_current_sos doesn't have to change at all.

Now, in order to do this, we need to move the add_vsyscall_page
call earlier, before svr4_current_dsos is ever called, in order
to read the vdso bfd out of memory before we ever first need to
filter out the vdso.  The cleanest I could do with the current
gdbarch_vsyscall_range-based design was to do the add_vsyscall_page
call from within gdbarch_vsyscall_range.  But that looks very ugly
to me, for reading symbols from a quite innocent looking gdbarch hook.

So I bit the bullet and made a custom Linux-specific
struct solib_ops that inherits svr4_so_ops, and overrides a couple
methods for vDSO awareness.  I think the end result is clearer
and probably more extensible if/when we decide to do the work necessary
to be able to show the vdso in "info sharedlibrary", without causing
could-not-find-file warnings.

I'm attaching two patches; the first implements the new solib_ops
instance, and then the second uses the vDSO's bfd size, fixing the
bug.

Passes testing on x86_64 Fedora 23 here, as well as the new test.

Let me know what you think.

Pedro Alves

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Introduce-linux_solib_ops.patch
Type: text/x-patch
Size: 36697 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160819/a212a52d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-vDSO-detection-work-with-core-files.patch
Type: text/x-patch
Size: 8578 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160819/a212a52d/attachment-0001.bin>