Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: Remove 'run cleanup chain'
Date: Wed, 14 Nov 2007 12:54:00 -0000	[thread overview]
Message-ID: <200711141553.54912.vladimir@codesourcery.com> (raw)

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


GDB now has a special 'run cleanup chain', but it seems to
be not really needed.

This cleanup chain is only used to call clear_solib in response
to 'run' command. However:
   - Just calling clear_solib is much simpler
   - We need to call clear_solib for attach, too, and it's done
   via direct call, so it's better to have run be similar to
   attach.

There's comment in jv-lang.c that hints that the run cleanup can
be useful, but is broken, and the code containing the
comment is not actually used itself.

So, it seems to me that carrying this general code for the
sake of a single client that is only complicated as result is not good,
here's a patch to remove run cleanup chain. OK?

- Volodya

[-- Attachment #2: run_cleanup.diff --]
[-- Type: text/x-diff, Size: 5076 bytes --]

commit ec9c7853b07801d6c4b0973156e5e5dfee5ead2f
Author: Vladimir Prus <vladimir@codesourcery.com>
Date:   Wed Nov 14 15:43:07 2007 +0300

    Remove 'run_cleanup'.

diff --git a/gdb/defs.h b/gdb/defs.h
index 8cfc6e3..deaa528 100644
--- a/gdb/defs.h
+++ b/gdb/defs.h
@@ -347,7 +347,6 @@ extern char *safe_strerror (int);
 
 extern void do_cleanups (struct cleanup *);
 extern void do_final_cleanups (struct cleanup *);
-extern void do_run_cleanups (struct cleanup *);
 extern void do_exec_cleanups (struct cleanup *);
 extern void do_exec_error_cleanups (struct cleanup *);
 
@@ -383,8 +382,6 @@ extern struct cleanup *make_final_cleanup (make_cleanup_ftype *, void *);
 extern struct cleanup *make_my_cleanup (struct cleanup **,
 					make_cleanup_ftype *, void *);
 
-extern struct cleanup *make_run_cleanup (make_cleanup_ftype *, void *);
-
 extern struct cleanup *make_exec_cleanup (make_cleanup_ftype *, void *);
 extern struct cleanup *make_exec_error_cleanup (make_cleanup_ftype *, void *);
 
diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 079d586..e8ac46a 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -482,7 +482,7 @@ run_command_1 (char *args, int from_tty, int tbreak_at_main)
   /* Purge old solib objfiles. */
   objfile_purge_solibs ();
 
-  do_run_cleanups (NULL);
+  clear_solib ();
 
   /* The comment here used to read, "The exec file is re-read every
      time we do a generic_mourn_inferior, so we just have to worry
diff --git a/gdb/jv-lang.c b/gdb/jv-lang.c
index a426d61..e3c6299 100644
--- a/gdb/jv-lang.c
+++ b/gdb/jv-lang.c
@@ -1133,25 +1133,3 @@ _initialize_java_language (void)
 
   add_language (&java_language_defn);
 }
-
-/* Cleanup code that should be run on every "run".
-   We should use make_run_cleanup to have this be called.
-   But will that mess up values in value histry?  FIXME */
-
-extern void java_rerun_cleanup (void);
-void
-java_rerun_cleanup (void)
-{
-  if (class_symtab != NULL)
-    {
-      free_symtab (class_symtab);	/* ??? */
-      class_symtab = NULL;
-    }
-  if (dynamics_objfile != NULL)
-    {
-      free_objfile (dynamics_objfile);
-      dynamics_objfile = NULL;
-    }
-
-  java_object_type = NULL;
-}
diff --git a/gdb/solib.c b/gdb/solib.c
index f687558..0ec0a51 100644
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -86,12 +86,8 @@ struct target_so_ops *current_target_so_ops;
 
 static struct so_list *so_list_head;	/* List of known shared objects */
 
-static int solib_cleanup_queued = 0;	/* make_run_cleanup called */
-
 /* Local function prototypes */
 
-static void do_clear_solib (void *);
-
 /* If non-empty, this is a search path for loading non-absolute shared library
    symbol files.  This takes precedence over the environment variables PATH
    and LD_LIBRARY_PATH.  */
@@ -506,15 +502,6 @@ update_solib_list (int from_tty, struct target_ops *target)
 		  "Error reading attached process's symbol file.\n",
 		  RETURN_MASK_ALL);
 
-  /* Since this function might actually add some elements to the
-     so_list_head list, arrange for it to be cleaned up when
-     appropriate.  */
-  if (!solib_cleanup_queued)
-    {
-      make_run_cleanup (do_clear_solib, NULL);
-      solib_cleanup_queued = 1;
-    }
-
   /* GDB and the inferior's dynamic linker each maintain their own
      list of currently loaded shared objects; we want to bring the
      former in sync with the latter.  Scan both lists, seeing which
@@ -866,13 +853,6 @@ clear_solib (void)
   ops->clear_solib ();
 }
 
-static void
-do_clear_solib (void *dummy)
-{
-  solib_cleanup_queued = 0;
-  clear_solib ();
-}
-
 /* GLOBAL FUNCTION
 
    solib_create_inferior_hook -- shared library startup support
@@ -955,7 +935,7 @@ void
 no_shared_libraries (char *ignored, int from_tty)
 {
   objfile_purge_solibs ();
-  do_clear_solib (NULL);
+  clear_solib ();
 }
 
 static void
diff --git a/gdb/utils.c b/gdb/utils.c
index af2fac8..3be084e 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -96,7 +96,6 @@ static void set_width (void);
 
 static struct cleanup *cleanup_chain;	/* cleaned up after a failed command */
 static struct cleanup *final_cleanup_chain;	/* cleaned up when gdb exits */
-static struct cleanup *run_cleanup_chain;	/* cleaned up on each 'run' */
 static struct cleanup *exec_cleanup_chain;	/* cleaned up on each execution command */
 /* cleaned up on each error from within an execution command */
 static struct cleanup *exec_error_cleanup_chain;
@@ -210,12 +209,6 @@ make_final_cleanup (make_cleanup_ftype *function, void *arg)
 }
 
 struct cleanup *
-make_run_cleanup (make_cleanup_ftype *function, void *arg)
-{
-  return make_my_cleanup (&run_cleanup_chain, function, arg);
-}
-
-struct cleanup *
 make_exec_cleanup (make_cleanup_ftype *function, void *arg)
 {
   return make_my_cleanup (&exec_cleanup_chain, function, arg);
@@ -324,12 +317,6 @@ do_final_cleanups (struct cleanup *old_chain)
 }
 
 void
-do_run_cleanups (struct cleanup *old_chain)
-{
-  do_my_cleanups (&run_cleanup_chain, old_chain);
-}
-
-void
 do_exec_cleanups (struct cleanup *old_chain)
 {
   do_my_cleanups (&exec_cleanup_chain, old_chain);

             reply	other threads:[~2007-11-14 12:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14 12:54 Vladimir Prus [this message]
2007-11-14 22:44 ` Jim Blandy
2007-11-15  6:25   ` Vladimir Prus
2007-11-15  7:05     ` Markus Deuling
2007-11-15  7:12       ` Vladimir Prus

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=200711141553.54912.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --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