Re: source listing change

[Jim Blandy <jimb@zwingli.cygnus.com>]

> >> I think that this has been discussed in the past.  Do we really need to
> >> make this a separate option to list?
> >Honestly, I didn't do any research to see if there was any discussion. 
> >Anyone remember?  I'd like to see it as the default.  It's a great
> >visual clue.
> I vaguely recall that people were concerned that changing this may cause
> problems for things like ddd, insight, emacs or anything else which
> interprets output from gdb.

To be honest, I don't think we should avoid making good changes to
GDB's output simply because it might break some program foolish enough
to try to parse it.  That's so limiting.

Given that it's not going to break Emacs, Insight, or much of the test
suites, I think this change is a shoo-in.
From jimb@zwingli.cygnus.com Wed Apr 05 13:31:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Christopher Blizzard <blizzard@mozilla.org>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: problems loading shared libraries - with attached test case
Date: Wed, 05 Apr 2000 13:31:00 -0000
Message-id: <npk8icwars.fsf@zwingli.cygnus.com>
References: <38DFD84E.9F330EC1@mozilla.org> <38E2D221.ADC270BF@mozilla.org> <npog7rxfke.fsf@zwingli.cygnus.com> <38E95507.FDD4C527@mozilla.org>
X-SW-Source: 2000-04/msg00100.html
Content-length: 6636

> Good point, I missed that case.  Damn.  Thanks for spending the time on
> this, Jim.
> 
> While we're talking about this I've noticed a behavior change with
> respect to the way the "info sharedlibrary" command works.  It now
> forces all the shared libraries to load which is bad(tm).  I've done
> that a few times and had to kill gdb after it sucked up a couple hundred
> meg of memory. :)

Oy!  Try this:

2000-04-05  Jim Blandy  <jimb@redhat.com>

	* solib.c (update_solib_list): New function.
	(solib_add): Call update_solib_list, and then read symbols.
	(info_sharedlibrary_command): Call update_solib_list, not
	solib_add.

Index: gdb/solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.8
diff -c -r1.8 solib.c
*** gdb/solib.c	2000/04/03 17:45:17	1.8
--- gdb/solib.c	2000/04/05 20:28:46
***************
*** 1194,1216 ****
  
  /* LOCAL FUNCTION
  
!    solib_add -- synchronize GDB's shared object list with the inferior's
  
     SYNOPSIS
  
!    void solib_add (char *pattern, int from_tty, struct target_ops *TARGET)
! 
!    DESCRIPTION
  
     Extract the list of currently loaded shared objects from the
!    inferior, and compare it with the list of shared objects for which
!    GDB has currently loaded symbolic information.  If new shared
!    objects have been loaded, or old shared objects have disappeared,
!    make the appropriate changes to GDB's tables.
  
!    If PATTERN is non-null, read symbols only for shared objects
!    whose names match PATTERN.
  
     If FROM_TTY is non-null, feel free to print messages about what
     we're doing.
  
--- 1194,1216 ----
  
  /* LOCAL FUNCTION
  
!    update_solib_list --- synchronize GDB's shared object list with inferior's
  
     SYNOPSIS
  
!    void update_solib_list (int from_tty, struct target_ops *TARGET)
  
     Extract the list of currently loaded shared objects from the
!    inferior, and compare it with the list of shared objects currently
!    in GDB's so_list_head list.  Edit so_list_head to bring it in sync
!    with the inferior's new list.
  
!    If we notice that the inferior has unloaded some shared objects,
!    free any symbolic info GDB had read about those shared objects.
  
+    Don't load symbolic info for any new shared objects; just add them
+    to the list, and leave their symbols_loaded flag clear.
+ 
     If FROM_TTY is non-null, feel free to print messages about what
     we're doing.
  
***************
*** 1222,1228 ****
     processes we've just attached to, so that's okay.  */
  
  void
! solib_add (char *pattern, int from_tty, struct target_ops *target)
  {
    struct so_list *inferior = current_sos ();
    struct so_list *gdb, **gdb_link;
--- 1222,1228 ----
     processes we've just attached to, so that's okay.  */
  
  void
! update_solib_list (int from_tty, struct target_ops *target)
  {
    struct so_list *inferior = current_sos ();
    struct so_list *gdb, **gdb_link;
***************
*** 1239,1252 ****
  
  #endif SVR4_SHARED_LIBS
  
-   if (pattern)
-     {
-       char *re_err = re_comp (pattern);
- 
-       if (re_err)
- 	error ("Invalid regexp: %s", re_err);
-     }
- 
    /* Since this function might actually add some elements to the
       so_list_head list, arrange for it to be cleaned up when
       appropriate.  */
--- 1239,1244 ----
***************
*** 1262,1277 ****
       shared objects appear where.  There are three cases:
  
       - A shared object appears on both lists.  This means that GDB
!        knows about it already, and it's still loaded in the inferior.
!        Nothing needs to happen.
  
       - A shared object appears only on GDB's list.  This means that
!        the inferior has unloaded it.  We should remove the shared
!        object from GDB's tables.
  
       - A shared object appears only on the inferior's list.  This
!        means that it's just been loaded.  We should add it to GDB's
!        tables.
  
       So we walk GDB's list, checking each entry to see if it appears
       in the inferior's list too.  If it does, no action is needed, and
--- 1254,1269 ----
       shared objects appear where.  There are three cases:
  
       - A shared object appears on both lists.  This means that GDB
!      knows about it already, and it's still loaded in the inferior.
!      Nothing needs to happen.
  
       - A shared object appears only on GDB's list.  This means that
!      the inferior has unloaded it.  We should remove the shared
!      object from GDB's tables.
  
       - A shared object appears only on the inferior's list.  This
!      means that it's just been loaded.  We should add it to GDB's
!      tables.
  
       So we walk GDB's list, checking each entry to see if it appears
       in the inferior's list too.  If it does, no action is needed, and
***************
*** 1374,1384 ****
  	    }
  	}
      }
  
!   /* Finally, read the symbols as requested.  Walk the list of
!      currently loaded shared libraries, and read symbols for any that
!      match the pattern --- or any whose symbols aren't already loaded,
!      if no pattern was given.  */
    {
      int any_matches = 0;
      int loaded_any_symbols = 0;
--- 1366,1408 ----
  	    }
  	}
      }
+ }
+ 
+ 
+ /* GLOBAL FUNCTION
+ 
+    solib_add -- read in symbol info for newly added shared libraries
+ 
+    SYNOPSIS
+ 
+    void solib_add (char *pattern, int from_tty, struct target_ops *TARGET)
+ 
+    DESCRIPTION
+ 
+    Read in symbolic information for any shared objects whose names
+    match PATTERN.  (If we've already read a shared object's symbol
+    info, leave it alone.)  If PATTERN is zero, read them all.
+ 
+    FROM_TTY and TARGET are as described for update_solib_list, above.  */
+ 
+ void
+ solib_add (char *pattern, int from_tty, struct target_ops *target)
+ {
+   struct so_list *gdb;
+ 
+   if (pattern)
+     {
+       char *re_err = re_comp (pattern);
+ 
+       if (re_err)
+ 	error ("Invalid regexp: %s", re_err);
+     }
+ 
+   update_solib_list (from_tty, target);
  
!   /* Walk the list of currently loaded shared libraries, and read
!      symbols for any that match the pattern --- or any whose symbols
!      aren't already loaded, if no pattern was given.  */
    {
      int any_matches = 0;
      int loaded_any_symbols = 0;
***************
*** 1466,1472 ****
    addr_fmt = "016l";
  #endif
  
!   solib_add (0, 0, 0);
  
    for (so = so_list_head; so; so = so->next)
      {
--- 1490,1496 ----
    addr_fmt = "016l";
  #endif
  
!   update_solib_list (from_tty, 0);
  
    for (so = so_list_head; so; so = so->next)
      {
From blizzard@mozilla.org Wed Apr 05 14:48:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: source listing change
Date: Wed, 05 Apr 2000 14:48:00 -0000
Message-id: <38EBB510.D5B9BFBA@mozilla.org>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <npln2swbzh.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00101.html
Content-length: 1163

Jim Blandy wrote:
> 
> > >> I think that this has been discussed in the past.  Do we really need to
> > >> make this a separate option to list?
> > >Honestly, I didn't do any research to see if there was any discussion.
> > >Anyone remember?  I'd like to see it as the default.  It's a great
> > >visual clue.
> > I vaguely recall that people were concerned that changing this may cause
> > problems for things like ddd, insight, emacs or anything else which
> > interprets output from gdb.
> 
> To be honest, I don't think we should avoid making good changes to
> GDB's output simply because it might break some program foolish enough
> to try to parse it.  That's so limiting.
> 
> Given that it's not going to break Emacs, Insight, or much of the test
> suites, I think this change is a shoo-in.

Someone has to take the lead and actually check it in then.  I submitted
the patch for someone else but don't have access to check it in.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I don't think I'm alone when I say I'd like to see more and more
planets fall under the ruthless domination of our solar system.
------------
From blizzard@mozilla.org Wed Apr 05 15:59:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: problems loading shared libraries - with attached test case
Date: Wed, 05 Apr 2000 15:59:00 -0000
Message-id: <38EBC5AD.2D9F65A9@mozilla.org>
References: <38DFD84E.9F330EC1@mozilla.org> <38E2D221.ADC270BF@mozilla.org> <npog7rxfke.fsf@zwingli.cygnus.com> <38E95507.FDD4C527@mozilla.org> <npk8icwars.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00102.html
Content-length: 970

Jim Blandy wrote:
> 
> > Good point, I missed that case.  Damn.  Thanks for spending the time on
> > this, Jim.
> >
> > While we're talking about this I've noticed a behavior change with
> > respect to the way the "info sharedlibrary" command works.  It now
> > forces all the shared libraries to load which is bad(tm).  I've done
> > that a few times and had to kill gdb after it sucked up a couple hundred
> > meg of memory. :)
> 
> Oy!  Try this:
> 
> 2000-04-05  Jim Blandy  <jimb@redhat.com>
> 
>         * solib.c (update_solib_list): New function.
>         (solib_add): Call update_solib_list, and then read symbols.
>         (info_sharedlibrary_command): Call update_solib_list, not
>         solib_add.

Yep, works fine now.  Thanks!

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I don't think I'm alone when I say I'd like to see more and more
planets fall under the ruthless domination of our solar system.
------------
From dan@cgsoftware.com Wed Apr 05 16:38:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Christopher Blizzard <blizzard@mozilla.org>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: source listing change
Date: Wed, 05 Apr 2000 16:38:00 -0000
Message-id: <Pine.LNX.4.10.10004051636400.13009-100000@propylaea.anduin.com>
References: <38EBB510.D5B9BFBA@mozilla.org>
X-SW-Source: 2000-04/msg00103.html
Content-length: 389

I merged it properly, but i noticed a small problem:
What it really does is always list the 10 lines where the current context
is.
It doesn't mark the current line otherwise.
I'm working on making this work.

> 
> Someone has to take the lead and actually check it in then.  I submitted
> the patch for someone else but don't have access to check it in.
> 
> --Chris
> 
> ------------
>