Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: ppluzhnikov@google.com (Paul Pluzhnikov)
To: gdb-patches@sourceware.org
Cc: ppluzhnikov@google.com
Subject: [RFC][patch] Avoid repeated calls to solib_add on initial attach.
Date: Fri, 15 Jul 2011 20:58:00 -0000	[thread overview]
Message-ID: <20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com> (raw)

Greetings,

Following up on my earlier "slow on high-latency links" message:
http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ...

Attached patch avoids calling solib_add twice when initially attaching
inferior.

I am not entirely happy about this patch, but don't have a better idea
for a fix, and do want to avoid repeated rescans of the shared library list.

(Some of our executables use 4000+ shared libraries, and the time in
solib_add does add up.)

Tested on Linux/x86_64, no regressions.

Comments?

Thanks,
--
Paul Pluzhnikov



2011-07-15  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* inferior.h (struct inferior): Add solib_add_generation.
	* infcmd.c (post_create_inferior): Only call solib_add if not
	already done.
	* solib.c (solib_add): Increment solib_add_generation.



Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.160
diff -u -p -r1.160 inferior.h
--- inferior.h	3 Jun 2011 15:32:44 -0000	1.160
+++ inferior.h	15 Jul 2011 20:10:20 -0000
@@ -536,6 +536,9 @@ struct inferior
      if any catching is necessary.  */
   int total_syscalls_count;
 
+  /* This counts the number of solib_add() calls performed.  */
+  int solib_add_generation;
+
   /* Per inferior data-pointers required by other GDB modules.  */
   void **data;
   unsigned num_data;
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.149
diff -u -p -r1.149 solib.c
--- solib.c	30 Jun 2011 19:29:54 -0000	1.149
+++ solib.c	15 Jul 2011 20:10:20 -0000
@@ -914,6 +914,8 @@ solib_add (char *pattern, int from_tty,
 {
   struct so_list *gdb;
 
+  current_inferior ()->solib_add_generation++;
+
   if (pattern)
     {
       char *re_err = re_comp (pattern);
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.287
diff -u -p -r1.287 infcmd.c
--- infcmd.c	30 May 2011 18:04:32 -0000	1.287
+++ infcmd.c	15 Jul 2011 20:50:56 -0000
@@ -398,6 +398,7 @@ void
 post_create_inferior (struct target_ops *target, int from_tty)
 {
   volatile struct gdb_exception ex;
+  int solib_add_generation;
 
   /* Be sure we own the terminal in case write operations are performed.  */ 
   target_terminal_ours ();
@@ -419,6 +420,7 @@ post_create_inferior (struct target_ops 
   if (ex.reason < 0 && ex.error != NOT_AVAILABLE_ERROR)
     throw_exception (ex);
 
+  solib_add_generation = current_inferior ()->solib_add_generation;
   if (exec_bfd)
     {
       /* Create the hooks to handle shared library load and unload
@@ -432,14 +434,16 @@ post_create_inferior (struct target_ops 
 
   /* If the solist is global across processes, there's no need to
      refetch it here.  */
-  if (exec_bfd && !gdbarch_has_global_solist (target_gdbarch))
+  if (exec_bfd && !gdbarch_has_global_solist (target_gdbarch)
+      && current_inferior ()->solib_add_generation == solib_add_generation)
     {
       /* Sometimes the platform-specific hook loads initial shared
 	 libraries, and sometimes it doesn't.  If it doesn't FROM_TTY will be
 	 incorrectly 0 but such solib targets should be fixed anyway.  If we
 	 made all the inferior hook methods consistent, this call could be
 	 removed.  Call it only after the solib target has been initialized by
-	 solib_create_inferior_hook.  */
+	 solib_create_inferior_hook.  Only do this if not alreay done from
+	 inside solib_create_inferior_hook.  */
 
 #ifdef SOLIB_ADD
       SOLIB_ADD (NULL, 0, target, auto_solib_add);


             reply	other threads:[~2011-07-15 20:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-15 20:58 Paul Pluzhnikov [this message]
2011-07-20 13:56 ` Gary Benson
2011-07-20 14:59 ` Pedro Alves
2011-07-20 16:15   ` Paul Pluzhnikov
2011-07-20 16:56     ` Pedro Alves
2011-07-20 16:59       ` Paul Pluzhnikov
2011-07-20 17:36         ` Pedro Alves
2011-07-20 18:38       ` Pedro Alves
2011-07-22 17:27         ` Paul Pluzhnikov
2011-07-22 17:51           ` Pedro Alves
2011-07-22 17:36     ` Tom Tromey
2011-07-22 17:43       ` 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=20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com \
    --to=ppluzhnikov@google.com \
    --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