public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
To: gdb-patches@sourceware.org
Subject: impossible to resolve symbols in same binary loaded twice with dlmopen
Date: Wed, 07 Jul 2010 18:49:00 -0000	[thread overview]
Message-ID: <1278528582.10151.23.camel@localhost.localdomain> (raw)

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

hi,

A couple of months ago, I reported on the gdb mailing-list this issue:
http://sourceware.org/ml/gdb/2010-02/msg00027.html (the original report
mentionned a crash which happened with a different program loader but
the root cause of the problem is the same as the one mentionned here)
and tom tromey gave hints on how it could be fixed. It took me a while
to eventually put together a patch and a reduced testcase for this issue
but here it is in the bugzilla database:
http://sourceware.org/bugzilla/show_bug.cgi?id=11766

For convenience, this email contains the reduced testcase and patch
attached. Here is the associated ChangeLog entry:

2010-XX-XX Mathieu Lacage <mathieu.lacage@inria.fr>

        Fix PR/gdb 11766: gdb does not resolve correctly symbols in
binaries loaded twice with dlmopen

        Because the name of an inferior binary present in the linkmap is
not sufficient for the test of uniqueness, of an entry in the list of
objfiles, we ensure uniqueness with an extra equality condition, the
addr_low member of the binary.

        * gdb/objfiles.h: add addr_low member variable
        * gdb/solib.c (solib_read_symbols): check for addr_low in
equality test for objfile, initialize addr_low if needed.


I really care about fixing this issue because it hits me and a lot of my
users and asking them to recompile gdb with a patch is not fun in the
long run. I am looking forward to fix this upstream so, please, let me
know what I can do to help with the resolution of this issue.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
Tel: +33 4 9238 5056

[-- Attachment #2: test.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 673 bytes --]

[-- Attachment #3: patch --]
[-- Type: text/plain, Size: 1774 bytes --]

? objdir
? patch
Index: gdb/objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.72
diff -c -p -r1.72 objfiles.h
*** gdb/objfiles.h	14 Apr 2010 17:26:11 -0000	1.72
--- gdb/objfiles.h	7 Jul 2010 18:35:38 -0000
*************** struct objfile
*** 193,198 ****
--- 193,200 ----
  
      char *name;
  
+     CORE_ADDR addr_low;
+ 
      /* Some flag bits for this objfile. */
  
      unsigned short flags;
Index: gdb/solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.140
diff -c -p -r1.140 solib.c
*** gdb/solib.c	16 May 2010 23:49:58 -0000	1.140
--- gdb/solib.c	7 Jul 2010 18:35:39 -0000
*************** solib_read_symbols (struct so_list *so, 
*** 634,644 ****
        TRY_CATCH (e, RETURN_MASK_ERROR)
  	{
  	  struct section_addr_info *sap;
- 
  	  /* Have we already loaded this shared object?  */
  	  ALL_OBJFILES (so->objfile)
  	    {
! 	      if (strcmp (so->objfile->name, so->so_name) == 0)
  		break;
  	    }
  	  if (so->objfile != NULL)
--- 634,644 ----
        TRY_CATCH (e, RETURN_MASK_ERROR)
  	{
  	  struct section_addr_info *sap;
  	  /* Have we already loaded this shared object?  */
  	  ALL_OBJFILES (so->objfile)
  	    {
! 	      if (strcmp (so->objfile->name, so->so_name) == 0
! 		  && so->objfile->addr_low == so->addr_low)
  		break;
  	    }
  	  if (so->objfile != NULL)
*************** solib_read_symbols (struct so_list *so, 
*** 648,653 ****
--- 648,654 ----
  							    so->sections_end);
  	  so->objfile = symbol_file_add_from_bfd (so->abfd,
  						  flags, sap, OBJF_SHARED);
+ 	  so->objfile->addr_low = so->addr_low;
  	  free_section_addr_info (sap);
  	}
  

             reply	other threads:[~2010-07-07 18:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 18:49 Mathieu Lacage [this message]
2010-07-08 20:32 ` Tom Tromey
2010-07-09 11:37   ` Mathieu Lacage
2010-07-09 11:42     ` Mathieu Lacage
2010-07-20 19:38     ` Tom Tromey
2010-07-25 12:25       ` Mathieu Lacage
2011-01-20 14:51         ` Mathieu Lacage
2011-01-26 10:52           ` Thiago Jung Bauermann
2011-01-28 11:10             ` Tom Tromey
2011-01-29 10:32               ` Thiago Jung Bauermann
2011-01-31 17:50                 ` Tom Tromey
2010-07-08 15:59 Mathieu Lacage

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=1278528582.10151.23.camel@localhost.localdomain \
    --to=mathieu.lacage@sophia.inria.fr \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).