This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] Call target_pre_inferior *after* clear_solib


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]