Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc] Call target_pre_inferior *after* clear_solib
Date: Fri, 08 Aug 2008 18:15:00 -0000	[thread overview]
Message-ID: <200808081814.m78IEdm1025988@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20080530202239.GA2715@caradoc.them.org> from "Daniel Jacobowitz" at May 30, 2008 04:22:39 PM

Daniel Jacobowitz wrote:
> On Fri, May 30, 2008 at 08:17:50PM +0200, Ulrich Weigand wrote:
> > -  /* Clean up any leftovers from other runs.  Some other things from
> > -     this function should probably be moved into target_pre_inferior.  */
> > -  target_pre_inferior (from_tty);
> > -
> >    /* Purge old solib objfiles. */
> >    objfile_purge_solibs ();
> >  
> >    clear_solib ();
> >  
> > +  /* Clean up any leftovers from other runs.  Some other things from
> > +     this function should probably be moved into target_pre_inferior.  */
> > +  target_pre_inferior (from_tty);
> > +
> 
> If the order is important, perhaps those two should move into
> target_pre_inferior?
> 
> The other option could be to clean up the handling of solibs so that
> each solib_ops gets a chance to discard.  I've long suspected we
> should allow more than a 1:1 relationship.

I'm finally getting back to this old patch, sorry for the delay ...

For now, I think the best way is to go with your first suggestion.  (This
makes sense on its own in any case to reduce code duplication, even if at
some later point we decide to implement multiple solib_ops as well.)

The following patch implements this.  Tested on spu-elf, powerpc-linux
and powerpc64-linux with no regressions.

What do you think?

Bye,
Ulrich

ChangeLog:

	* target.c: Include "solib.h".
	(target_pre_inferior): Call no_shared_libraries.
	* infcmd.c (run_command_1): Do not call objfile_purge_solibs
	or clear_solib.
	(attach_command): Do not call clear_solib.


Index: gdb/infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.196
diff -c -p -r1.196 infcmd.c
*** gdb/infcmd.c	26 Jul 2008 10:23:56 -0000	1.196
--- gdb/infcmd.c	8 Aug 2008 17:19:20 -0000
*************** run_command_1 (char *args, int from_tty,
*** 487,497 ****
       this function should probably be moved into target_pre_inferior.  */
    target_pre_inferior (from_tty);
  
-   /* Purge old solib objfiles. */
-   objfile_purge_solibs ();
- 
-   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
       about the symbol file."  The `generic_mourn_inferior' function
--- 487,492 ----
*************** attach_command (char *args, int from_tty
*** 2023,2046 ****
       this function should probably be moved into target_pre_inferior.  */
    target_pre_inferior (from_tty);
  
-   /* Clear out solib state. Otherwise the solib state of the previous
-      inferior might have survived and is entirely wrong for the new
-      target.  This has been observed on GNU/Linux using glibc 2.3. How
-      to reproduce:
- 
-      bash$ ./foo&
-      [1] 4711
-      bash$ ./foo&
-      [1] 4712
-      bash$ gdb ./foo
-      [...]
-      (gdb) attach 4711
-      (gdb) detach
-      (gdb) attach 4712
-      Cannot access memory at address 0xdeadbeef
-   */
-   clear_solib ();
- 
    if (args)
      {
        async_exec = strip_bg_char (&args);
--- 2018,2023 ----
Index: gdb/target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.169
diff -c -p -r1.169 target.c
*** gdb/target.c	9 Jul 2008 22:42:42 -0000	1.169
--- gdb/target.c	8 Aug 2008 17:19:21 -0000
***************
*** 40,45 ****
--- 40,46 ----
  #include "exceptions.h"
  #include "target-descriptions.h"
  #include "gdbthread.h"
+ #include "solib.h"
  
  static void target_info (char *, int);
  
*************** target_info (char *args, int from_tty)
*** 1717,1722 ****
--- 1718,1741 ----
  void
  target_pre_inferior (int from_tty)
  {
+   /* Clear out solib state. Otherwise the solib state of the previous
+      inferior might have survived and is entirely wrong for the new
+      target.  This has been observed on GNU/Linux using glibc 2.3. How
+      to reproduce:
+ 
+      bash$ ./foo&
+      [1] 4711
+      bash$ ./foo&
+      [1] 4712
+      bash$ gdb ./foo
+      [...]
+      (gdb) attach 4711
+      (gdb) detach
+      (gdb) attach 4712
+      Cannot access memory at address 0xdeadbeef
+   */
+   no_shared_libraries (NULL, from_tty);
+ 
    invalidate_target_mem_regions ();
  
    target_clear_description ();


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


       reply	other threads:[~2008-08-08 18:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080530202239.GA2715@caradoc.them.org>
2008-08-08 18:15 ` Ulrich Weigand [this message]
2008-08-08 18:28   ` Daniel Jacobowitz
2008-08-09 12:18     ` Ulrich Weigand

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=200808081814.m78IEdm1025988@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=drow@false.org \
    --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