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;
next 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