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

[Yao Qi <qiyaoltc at gmail dot com>]

Hi,
When I test gdb master/7.12 with glibc mainline on aarch64, I got the
following fail,

(gdb) core-file build-gdb/gdb/testsuite/outputs/gdb.base/corefile/corefile.core^M
[New LWP 2362]^M
warning: Could not load shared library symbols for linux-vdso.so.1.^M
Do you need "set solib-search-path" or "set sysroot"?^M
Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M
Program terminated with signal SIGABRT, Aborted.^M
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58^M
58      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.^M
(gdb) FAIL: gdb.base/corefile.exp: core-file warning-free

Looks the warning "Could not load shared library symbols for
linux-vdso.so.1." makes the trouble.  It was discussed and fixed in this
thread https://sourceware.org/ml/gdb-patches/2014-09/msg00361.html  In
the fix, we filter out the vDSO module if l_ld is in the range of vDSO
module.  However, it only works for native live debugging.  We can
know the starting address of vDSO by AT_SYSINFO_EHDR, but we don't know
size of vDSO when target is corefile.  In my observation, vDSO is _not_
dumped in corefile at all.

One version of Pedro's patch uses "(so->lm_info->l_addr_inferior
== vsyscall_addr)" to check whether "so" is vDSO (it works for me in my
fail here), but we changed it to range checking in order to handle
"prelinked" vDSO.  I go through the mail thread above, but I don't know
how vDSO is "prelinked".

Alternatively, we can filter vDSO by name matching, like "",
"linux-vdso.so.1" and "linux-gate.so.1", which was proposed by Doug
too.  Is it a good approach to fix this problem?

-- 
Yao (齐尧)