diff options
author | Pedro Alves <palves@redhat.com> | 2016-08-22 20:05:09 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2016-08-22 20:05:09 +0100 |
commit | 6bb90213cb7b8e2f3be20f2e46f11f57f0c9ce55 (patch) | |
tree | c4d9f2bf1199d01f59be4dc9b0c181432b008a49 /gdb/linux-tdep.c | |
parent | 5fbe0d878a691b9be42bb2bdebd027ac3dfd38c2 (diff) | |
download | binutils-gdb-6bb90213cb7b8e2f3be20f2e46f11f57f0c9ce55.tar.gz |
Fix PR gdb/20505 - Make vDSO detection work with core files
Loading a core dump that was either generated on a system running
pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused
set in the environment, solib-svr4.c:svr4_current_sos fails to filter
out the vDSO, resulting in:
(gdb) core-file 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
...
The problem is that gdbarch_vsyscall_range does not support core
inferiors at all.
When live debugging, we're finding the vDSO's start address with
auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the
corresponding mapping, by parsing /proc/PID/maps. When debugging a
core dump, we can also determine the starting address from
auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core
mappings out of the host's /proc. But we can instead look for a
corresponding load segment in the core's bfd.
gdb/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* linux-tdep.c (linux_vsyscall_range_raw): For core inferiors,
find the vDSO's start address with AT_SYSINFO_EHDR too, and
determine the vDSO's size by finding the PT_LOAD segment that
matches AT_SYSINFO_EHDR.
gdb/testsuite/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* gdb.base/vdso-warning.exp: Test core dumps too. Use
with_test_prefix. Factor out bits to ...
(test_no_vdso): ... this new procedure.
Diffstat (limited to 'gdb/linux-tdep.c')
-rw-r--r-- | gdb/linux-tdep.c | 35 |
1 files changed, 30 insertions, 5 deletions
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index ab110b0a687..718dc1ab662 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -2287,17 +2287,42 @@ linux_vsyscall_range_raw (struct gdbarch *gdbarch, struct mem_range *range) long pid; char *data; - /* Can't access /proc if debugging a core file. */ - if (!target_has_execution) + if (target_auxv_search (¤t_target, AT_SYSINFO_EHDR, &range->start) <= 0) return 0; + /* It doesn't make sense to access the host's /proc when debugging a + core file. Instead, look for the PT_LOAD segment that matches + the vDSO. */ + if (!target_has_execution) + { + Elf_Internal_Phdr *phdrs; + long phdrs_size; + int num_phdrs, i; + + phdrs_size = bfd_get_elf_phdr_upper_bound (core_bfd); + if (phdrs_size == -1) + return 0; + + phdrs = (Elf_Internal_Phdr *) alloca (phdrs_size); + num_phdrs = bfd_get_elf_phdrs (core_bfd, phdrs); + if (num_phdrs == -1) + return 0; + + for (i = 0; i < num_phdrs; i++) + if (phdrs[i].p_type == PT_LOAD + && phdrs[i].p_vaddr == range->start) + { + range->length = phdrs[i].p_memsz; + return 1; + } + + return 0; + } + /* We need to know the real target PID to access /proc. */ if (current_inferior ()->fake_pid_p) return 0; - if (target_auxv_search (¤t_target, AT_SYSINFO_EHDR, &range->start) <= 0) - return 0; - pid = current_inferior ()->pid; /* Note that reading /proc/PID/task/PID/maps (1) is much faster than |