Imagelibrary/binutils-gdb
1
0
Fork 1
mirror of https://github.com/bminor/binutils-gdb.git synced 2025-12-25 16:57:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix PR gdb/20505 - Make vDSO detection work with core files

Browse Source 
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.
This commit is contained in:
Pedro Alves
2016-08-22 20:05:09 +01:00
parent 5fbe0d878a
commit 6bb90213cb
4 changed files with 98 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
gdb/linux-tdep.c
View File

@@ -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