Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Blanc, Nicolas" <nicolas.blanc@intel.com>
Cc: Pedro Alves <palves@redhat.com>,
	       "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/3] Added command remove-symbol-file.
Date: Wed, 08 May 2013 17:56:00 -0000	[thread overview]
Message-ID: <518A91D0.5010205@redhat.com> (raw)
In-Reply-To: <388084C8C1E6A64FA36AD1D656E4856619DF0550@IRSMSX102.ger.corp.intel.com>

So what is the desirable behavior for when the user does
add-symbol-file and then the program loads the same file,
and then the user removes the file she added.  GDB drops
symbols until the next DSO event or next "sharedlibrary"
command invocation?  The fact that GDB reuses the same file
when the addr_low happens to match looks quite brittle (it
doesn't check the section offsets (passed to add-symbol-file)
are the same, for instance).  I wonder whether this sharing is
supposed to be a valid use case, and whether it wouldn't be better
and simpler to disable it, that is,

	  /* Have we already loaded this shared object?  */
	  ALL_OBJFILES (so->objfile)
	    {
	      if (filename_cmp (so->objfile->name, so->so_name) == 0
		  && so->objfile->addr_low == so->addr_low
-		  && so->objfile->addr_low == so->addr_low)
+                  && !(so->objfile->flags & OBJF_USERLOADED))
		break;
	    }

...

-	  /* Unless the user loaded it explicitly, free SO's objfile.  */
-	  if (gdb->objfile && ! (gdb->objfile->flags & OBJF_USERLOADED)
-	      && !solib_used (gdb))
-	    free_objfile (gdb->objfile);


In a way, treat manually added objfiles list and the dynamic SO list
separate lists.

-- 
Pedro Alves


  reply	other threads:[~2013-05-08 17:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 11:22 [PATCH 0/3] remove-symbol-file Nicolas Blanc
2013-04-16 11:51 ` [PATCH 2/3] Test adding and removing a symbol file at runtime Nicolas Blanc
2013-04-24 12:18   ` Tom Tromey
2013-04-24 12:18     ` Tom Tromey
2013-04-16 12:18 ` [PATCH 1/3] Command remove-symbol-file Nicolas Blanc
2013-04-16 13:25 ` [PATCH 1/3] Added command remove-symbol-file Nicolas Blanc
2013-04-22 13:32   ` Yao Qi
2013-04-24 18:54   ` Tom Tromey
2013-04-25 19:24     ` Blanc, Nicolas
2013-04-25 20:07       ` Tom Tromey
2013-04-26 14:13       ` Yao Qi
2013-04-26 20:23   ` Pedro Alves
2013-04-30  7:30     ` Blanc, Nicolas
2013-04-30  9:28       ` Pedro Alves
2013-04-30 16:53         ` Blanc, Nicolas
2013-05-08 17:56           ` Pedro Alves [this message]
2013-05-28 11:25             ` Blanc, Nicolas
2013-04-16 14:18 ` [PATCH 3/3] Documentation for the remove-symbol-file command Nicolas Blanc
2013-04-16 15:12   ` Eli Zaretskii
2013-04-24  9:22 ` [PATCH 0/3] remove-symbol-file Tom Tromey
2013-04-24 20:40   ` Blanc, Nicolas
2013-04-24 20:49     ` Pedro Alves
2013-04-25 17:25       ` Blanc, Nicolas
2013-04-26 19:13         ` Pedro Alves
2013-04-24 17:46 ` Pedro Alves

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=518A91D0.5010205@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nicolas.blanc@intel.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