Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Randolph Chung <randolph@tausq.org>
To: gdb-patches@sources.redhat.com
Subject: [rfa] Shared object matching for solib-som.c
Date: Wed, 19 Apr 2006 01:07:00 -0000	[thread overview]
Message-ID: <44458D3D.4030506@tausq.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Dave Anglin brought this problem to my attention -

Sometimes gdb does not properly relocate symbols in shared objects, 
leading to wrong backtraces and all sorts of problems. The problem seems 
to be that the SOM solib code builds section offsets by comparing object 
filenames between objfile->name so so_list->so_name, and because the two 
filenames could have gone through different types of postprocessing, 
they can differ subtly that makes the matching fail.

In the case I debugged, gdb was comparing
/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libjava/.libs/libgcj.sl.7
against
/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs/libgcj.sl.7

The attached patch changes the logic so that only the last component in 
the filename is compared. This of course assumes that you have not 
linked two shared objects with the same filename (hopefully not likely). 
This is not very robust either, but I think this is better than what we 
have before.

I notice that most of the solib variants do not need to do this type of 
processing; unfortunately I haven't figured out a better way to handle 
the SOM case. Perhaps somebody more familiar with the solib code/SOM can 
comment?

Meanwhile, is this patch ok?

randolph

[-- Attachment #2: solib.diff --]
[-- Type: text/x-patch, Size: 1407 bytes --]

2006-04-19  Randolph Chung  <tausq@debian.org>

	* solib-som.c (som_relocate_section_addresses): Cleanup formatting.
	(som_solib_section_offsets): Only compare filename to match shared
	object.

Index: solib-som.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-som.c,v
retrieving revision 1.9
diff -u -p -r1.9 solib-som.c
--- solib-som.c	24 Mar 2006 23:49:56 -0000	1.9
+++ solib-som.c	19 Apr 2006 00:57:21 -0000
@@ -127,11 +127,9 @@ som_relocate_section_addresses (struct s
     }
   else if (aflag & SEC_DATA)
     {
-      sec->addr    += so->lm_info->data_start; 
+      sec->addr    += so->lm_info->data_start;
       sec->endaddr += so->lm_info->data_start;
     }
-  else
-    ;
 }
 
 /* This hook gets called just before the first instruction in the
@@ -787,7 +794,21 @@ som_solib_section_offsets (struct objfil
     {
       /* Oh what a pain!  We need the offsets before so_list->objfile
          is valid.  The BFDs will never match.  Make a best guess.  */
-      if (strstr (objfile->name, so_list->so_name))
+      char *p1, *p2;
+
+      p1 = strrchr(objfile->name, '/');
+      p2 = strrchr(so_list->so_name, '/');
+
+      if (p1) 
+        p1++; 
+      else 
+        p1 = objfile->name;
+      if (p2)
+        p2++;
+      else
+        p2 = so_list->so_name;
+
+      if (strcmp (p1, p2) == 0)
 	{
 	  asection *private_section;
 

             reply	other threads:[~2006-04-19  1:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19  1:07 Randolph Chung [this message]
2006-04-19  8:15 ` Eli Zaretskii
2006-04-19  8:29   ` Randolph Chung
2006-04-19  9:07     ` Eli Zaretskii
2006-04-19 12:33 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44458D3D.4030506@tausq.org \
    --to=randolph@tausq.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox