From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16902 invoked by alias); 19 Apr 2006 01:07:17 -0000 Received: (qmail 16448 invoked by uid 22791); 19 Apr 2006 01:07:16 -0000 X-Spam-Check-By: sourceware.org Received: from ip127.bb146.pacific.net.hk (HELO mailhub.stlglobal.com) (202.64.146.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Apr 2006 01:07:12 +0000 Received: from localhost ([127.0.0.1]) by mailhub.stlglobal.com with esmtp (Exim 4.50) id 1FW19v-0007ee-E3 for gdb-patches@sources.redhat.com; Wed, 19 Apr 2006 09:07:07 +0800 Message-ID: <44458D3D.4030506@tausq.org> Date: Wed, 19 Apr 2006 01:07:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa] Shared object matching for solib-som.c Content-Type: multipart/mixed; boundary="------------000601000203070708030800" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00250.txt.bz2 This is a multi-part message in MIME format. --------------000601000203070708030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1234 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 --------------000601000203070708030800 Content-Type: text/x-patch; name="solib.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="solib.diff" Content-length: 1407 2006-04-19 Randolph Chung * 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; --------------000601000203070708030800--