This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH] Skip VDSO when reading SO list
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: gdb-patches at sourceware dot org
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Mon, 19 Aug 2013 16:44:13 +0200
- Subject: [PATCH] Skip VDSO when reading SO list
On some Linux versions, the file name (l_name) of a VDSO's link map
entry lies in read-only memory that is excluded from a core dump.
When reading such a core dump, GDB complains:
warning: Can't read pathname for load map: Input/output error.
When GDB walks through the link map again after establishing the file
mappings, the file name will be recognized as the empty string, and
the entry will be ignored. However, if the user supplied the wrong
version of the executable, a bogus entry with a garbage file name may
be created instead.
This patch tries to avoid the warning and the potential bogus entry.
In the cases I've looked at, the VDSO's l_name address matches that of
the main executable. Thus the patch uses this as a criteria for
identifying (and skipping) the VDSO.
2013-08-19 Andreas Arnez <arnez@linux.vnet.ibm.com>
* solib-svr4.c (svr4_read_so_list): Skip the VDSO when reading
link map entries.
Index: gdb/gdb/solib-svr4.c
===================================================================
--- gdb.orig/gdb/solib-svr4.c
+++ gdb/gdb/solib-svr4.c
@@ -1310,6 +1310,7 @@ static int
svr4_read_so_list (CORE_ADDR lm, CORE_ADDR prev_lm,
struct so_list ***link_ptr_ptr, int ignore_first)
{
+ struct so_list *first = NULL;
CORE_ADDR next_lm;
for (; lm != 0; prev_lm = lm, lm = next_lm)
@@ -1349,10 +1350,22 @@ svr4_read_so_list (CORE_ADDR lm, CORE_AD
{
struct svr4_info *info = get_svr4_info ();
+ first = new;
info->main_lm_addr = new->lm_info->lm_addr;
do_cleanups (old_chain);
continue;
}
+
+ /* The l_name of a VDSO sometimes lies in read-only memory that
+ is excluded from a core dump. In order to avoid the "can't
+ read pathname" warning, we try to identify the VDSO. One
+ criteria is that the l_name address matches that of the main
+ executable. */
+ if (first && new->lm_info->l_name == first->lm_info->l_name)
+ {
+ do_cleanups (old_chain);
+ continue;
+ }
/* Extract this shared object's name. */
target_read_string (new->lm_info->l_name, &buffer,