summaryrefslogtreecommitdiff
path: root/gdb/linux-tdep.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-08-22 20:05:09 +0100
committerPedro Alves <palves@redhat.com>2016-08-22 20:05:09 +0100
commit6bb90213cb7b8e2f3be20f2e46f11f57f0c9ce55 (patch)
treec4d9f2bf1199d01f59be4dc9b0c181432b008a49 /gdb/linux-tdep.c
parent5fbe0d878a691b9be42bb2bdebd027ac3dfd38c2 (diff)
downloadbinutils-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.c35
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 (&current_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 (&current_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