Forward from GNU volunteer coordination

["S. Morningthunder" <mthunder@gnu.org>]

This man shows interest in the over-the-ethernet debugger stub.


------- Start of forwarded message -------
Resent-From: GNU Mailing List Maintenance <gnu@gnu.org>
Resent-To: gvc@gnu.org
Date: Fri, 22 Oct 1999 22:19:48 -0400
From: mamin <mamin@oasis.on.ca>
To: gnu@gnu.org
Subject: Q. about [Kernel-Related Projects]

Hi,

I am C/C++ developer on various linux platforms. I read abou the
following project for FSF:

"Kernel-Related Projects

An over-the-ethernet debugger stub that will allow the kernel to be
debugged from GDB running on another machine. This stub needs its own
self-contained implementation of all protocols to be used, since the GNU
system will use user processes to implement all but the lowest levels,
and the stub won't be able to use those processes. If a simple
self-contained implementation of IP and TCP is impractical, it might be
necessary to design a new, simple protocol based directly on ethernet.
It's not crucial to support high speed or communicating across gateways.
It might be possible to use the Mach ethernet driver code, but it would
need some changes. "


I wish to know what are the current development tasks, how can I join? 

Thank you in advance,

yours,
Mohamed Amin
------- End of forwarded message -------
From cgf@cygnus.com Sun Oct 31 11:00:00 1999
From: cgf@cygnus.com (Chris Faylor)
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: --enable-profiling
Date: Sun, 31 Oct 1999 11:00:00 -0000
Message-id: <7vi2tg$ssf$1@cronkite.cygnus.com>
References: <87u2n97vaa.fsf@cygnus.com> <199910300045.RAA15367@andros.cygnus.com> <199910311504.HAA00905@ferrule.cygnus.com>
X-SW-Source: 1999-q4/msg00121.html
Content-length: 1046

In article < 199910311504.HAA00905@ferrule.cygnus.com >,
Tom Tromey  <tromey@cygnus.com> wrote:
>Stan> BTW, will this work with djgpp and/or cygwin?  What will happen
>Stan> if you try to configure on those with --enabling-profiling?
>
>It might work or it might not.  I don't know.  My theory is that
>profiling gdb is a maintainer thing, and if somebody uses
>--enable-profiling and it doesn't build, they had better know what
>they are doing anyway.  We can always add tests for functions later.
>I could add them now if it is important; it is easy enough to do.
>Ordinarily I'm zealous about portability, but in this case I don't
>think it matters that much.

DJ Delorie and Stan Cox made some changes to support profiling in Cygwin
last year.  So, I think that this will probably "work" as in it will
compile and link but it probably won't give terribly useful results.
Windows didn't provide some of the timing stuff that was crucial for
getting accurate information.

-chris
-- 
cgf@cygnus.com
http://www.cygnus.com/
From tromey@cygnus.com Sun Oct 31 11:59:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb-patches@sourceware.cygnus.com 
Subject: Patch: Updated --enable-profiling
Date: Sun, 31 Oct 1999 11:59:00 -0000
Message-id: <87r9ib70xq.fsf@cygnus.com>
X-SW-Source: 1999-q4/msg00122.html
Content-length: 7401

Here is an updated version of my --enable-profiling patch.
This one includes changes suggested by Stan and Michael.

1999-10-29  Tom Tromey  <tromey@cygnus.com>

	* config.in: Rebuilt.
	* acconfig.h (ENABLE_PROFILE): New #undef.
	* Makefile.in (PROFILE_CFLAGS): New macro.
	* configure: Rebuilt.
	* configure.in: Added --enable-profiling.  Define ENABLE_PROFILE
	if provided.  Set and subst PROFILE_CFLAGS.
	* maint.c (maint_profile_gdb): New function.
	(_initialize_maint_cmds): Add `profile-gdb' command if profiling
	support is enabled.
	* main.c (main): Turn off profiling if profiling support is
	enabled.

1999-10-31  Tom Tromey  <tromey@cygnus.com>

	* gdbint.texinfo (Profiling GDB): New node.


More comments / requests?  Or is this ok to commit?

Tom

Index: Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/Makefile.in,v
retrieving revision 1.662.2.4
diff -u -r1.662.2.4 Makefile.in
--- Makefile.in	1999/06/15 17:57:51	1.662.2.4
+++ Makefile.in	1999/10/31 19:51:21
@@ -206,7 +206,7 @@
 # M{H,T}_CFLAGS, if defined, have host- and target-dependent CFLAGS
 # from the config directory.
 GLOBAL_CFLAGS = $(MT_CFLAGS) $(MH_CFLAGS)
-#PROFILE_CFLAGS = -pg
+PROFILE_CFLAGS = @PROFILE_CFLAGS@
 
 # CFLAGS is specifically reserved for setting from the command line
 # when running make.  I.E.  "make CFLAGS=-Wmissing-prototypes".
Index: acconfig.h
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/acconfig.h,v
retrieving revision 2.19
diff -u -r2.19 acconfig.h
--- acconfig.h	1999/03/24 00:57:12	2.19
+++ acconfig.h	1999/10/31 19:51:23
@@ -96,3 +96,6 @@
 
 /* Set to true if the save_state_t structure has the ss_wide member */
 #define HAVE_STRUCT_MEMBER_SS_WIDE 0
+
+/* Define if profiling support should be enabled.  */
+#undef ENABLE_PROFILE
Index: config.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/config.in,v
retrieving revision 2.34
diff -u -r2.34 config.in
--- config.in	1999/03/24 00:57:12	2.34
+++ config.in	1999/10/31 19:51:25
@@ -129,6 +129,9 @@
 /* Set to true if the save_state_t structure has the ss_wide member */
 #define HAVE_STRUCT_MEMBER_SS_WIDE 0
 
+/* Define if profiling support should be enabled.  */
+#undef ENABLE_PROFILE
+
 /* Define if you have the __argz_count function.  */
 #undef HAVE___ARGZ_COUNT
 
Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/configure.in,v
retrieving revision 1.385.2.1
diff -u -r1.385.2.1 configure.in
--- configure.in	1999/04/15 22:53:46	1.385.2.1
+++ configure.in	1999/10/31 19:51:34
@@ -330,7 +330,16 @@
 
 dnl Handle optional features that can be enabled.
 ENABLE_CFLAGS=
+PROFILE_CFLAGS=
 
+AC_ARG_ENABLE(profiling,
+[  --enable-profiling      Turn on profiling of gdb])
+
+if test "$enable_profiling" =  yes; then
+   AC_DEFINE(ENABLE_PROFILE)
+   PROFILE_CFLAGS=-pg
+fi
+
 AC_ARG_ENABLE(tui,
 [  --enable-tui            Enable full-screen terminal user interface],
 [
@@ -681,6 +690,7 @@
 AC_SUBST(IGNORE_SIM_OBS)
 
 AC_SUBST(ENABLE_CFLAGS)
+AC_SUBST(PROFILE_CFLAGS)
 
 AC_SUBST(CONFIG_OBS)
 AC_SUBST(CONFIG_DEPS)
Index: main.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/main.c,v
retrieving revision 1.164.2.1
diff -u -r1.164.2.1 main.c
--- main.c	1999/04/15 22:53:48	1.164.2.1
+++ main.c	1999/10/31 19:51:41
@@ -128,6 +128,10 @@
 
   int gdb_file_size;
 
+#ifdef ENABLE_PROFILE
+  moncontrol (0);
+#endif
+
   START_PROGRESS (argv[0], 0);
 
 #ifdef MPW
Index: maint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/maint.c,v
retrieving revision 2.27
diff -u -r2.27 maint.c
--- maint.c	1999/04/02 23:11:57	2.27
+++ maint.c	1999/10/31 19:51:46
@@ -56,6 +56,11 @@
 
 static void maintenance_print_command PARAMS ((char *, int));
 
+#ifdef ENABLE_PROFILE
+static void maint_profile_gdb PARAMS ((char *, int));
+#endif
+
+
 /* Set this to the maximum number of seconds to wait instead of waiting forever
    in target_wait().  If this timer times out, then it generates an error and
    the command is aborted.  This replaces most of the need for timeouts in the
@@ -339,6 +344,26 @@
   return;
 }
 
+/* "maintenance profile-gdb <on|off>"  */
+static void
+maint_profile_gdb (char *arg, int from_tty)
+{
+#ifdef ENABLE_PROFILE
+  int val;
+  if (arg == NULL || ! *arg)
+    error ("requires argument (\"on\" or \"off\"");
+  if (! strcmp (arg, "on"))
+    val = 1;
+  else if (! strcmp (arg, "off"))
+    val = 0;
+  else
+    error ("unrecognized argument; must be \"on\" or \"off\"");
+  moncontrol (val);
+#else
+  error ("gdb was not configured with --enable-profiling");
+#endif
+}
+
 void
 _initialize_maint_cmds ()
 {
@@ -431,6 +456,12 @@
   add_cmd ("translate-address", class_maintenance, maintenance_translate_address,
 	   "Translate a section name and address to a symbol.",
 	   &maintenancelist);
+
+#ifdef ENABLE_PROFILE
+  add_cmd ("profile-gdb", class_maintenance, maint_profile_gdb,
+	   "Enable or disable profiling.",
+	   &maintenancelist);
+#endif
 
   add_show_from_set (
     add_set_cmd ("watchdog", class_maintenance, var_zinteger, (char *)&watchdog,
Index: doc/gdbint.texinfo
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v
retrieving revision 1.110
diff -u -r1.110 gdbint.texinfo
--- gdbint.texinfo	1999/04/12 12:32:53	1.110
+++ gdbint.texinfo	1999/10/31 19:52:27
@@ -2522,6 +2522,7 @@
 @menu
 * Getting Started::		Getting started working on GDB
 * Debugging GDB::		Debugging GDB with itself
+* Profiling GDB::               Profiling GDB
 @end menu
 
 @node Getting Started,,, Hints
@@ -2728,6 +2729,28 @@
 
 @end table
 
+@node Profiling GDB,,, Hints
+
+@section Profiling GDB
+
+GDB contains some support for profiling itself.  Currently this support
+is rudimentary.
+
+You can configure GDB with @samp{--enable-profiling}.  This does two
+things.  First, it arranges for GDB to be compiled and linked with
+@samp{-pg}.  (This might not work on all platforms; feel free to submit
+patches to fix this for your platform.)  Second, this configure flag
+arranges for the @code{maint profile-gdb} command to be enabled.
+
+@code{maint profile-gdb} takes a single argument, which must be
+@samp{on} or @samp{off}.  This command enables or disables profiling of
+gdb, and can be used to limit profiling to a chosen set of user
+commands.
+
+Note that when configured this way, GDB disables profiling in
+@code{main}.  If you want to profile GDB's initialization code, you will
+have to arrange to build GDB with @code{-pg} but without
+@samp{ENABLE_PROFILE} defined.
 
 @contents
 @bye
Index: NEWS
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/NEWS,v
retrieving revision 2.58
diff -u -r2.58 NEWS
--- NEWS	1999/04/13 00:17:35	2.58
+++ NEWS	1999/10/31 19:56:39
@@ -7,6 +7,12 @@
 
 TI TMS320C80					tic80-*-*
 
+* Profiling for gdb
+
+If gdb is configured with `--enable-profiling', then gdb is built with
+`-pg' and a new `maintenance profile-gdb' command is created.  This
+command can be used to enable or disable profiling, making it possible
+to profile a single command or set of commands.
 
 *** Changes in GDB-4.18:
 
From kingdon@redhat.com Sun Oct 31 16:48:00 1999
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Cc: robertl@sco.com
Subject: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Sun, 31 Oct 1999 16:48:00 -0000
Message-id: <199911010048.TAA07679@devserv.devel.redhat.com>
X-SW-Source: 1999-q4/msg00123.html
Content-length: 4740

The following looks OK to me (well, I haven't looked into the ptrace
header lossage stuff but I can tell you we are shipping a similar
patch).

------- Start of forwarded message -------
Return-Path: <robertl@sco.com>
Date: Fri, 29 Oct 1999 17:22:51 -0500
From: Robert Lipe <robertl@sco.com>
To: kingdon@redhat.com
Subject: threads RH6/Sparc vs. GDB
Content-Type: text/plain; charset=us-ascii

Hi, Jim.

I hope everything is going well for you at your new gig.  I had a reason
to revisit my threaded app on RH6.0/Sparc with GDB.  With minor mods
to the code in the GDB tree that I flagtrantly (attached) cabbaged
from your work, GDB no longer goes completely down in flames.  I offer
these under the "trivial and obvious" clause in hope that you see a
way to stick these someplace so that each Linux port isn't left to
fend for thier own.  (Since I have only a lowly classic, builds are
really painful for me.  I suppose I could cross build it from a modern
computer, but I don't know that would really be any faster once I got
done screwing around with libraries and headers...)

. . .

I now see the tell-tale
	[New Thread 18244 (manager thread)]
	[New Thread 18239 (initial thread)]
	[New Thread 18245]
messages at startup.   Stack traces are toast, but things are much more
resonable right now.

So consider those patches as an improvement.   I didn't include a changelog
becuase, well, they're your code. :-)

. . .

Thanx for any help you can offer.
RJL


Index: infptrace.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 infptrace.c
- --- infptrace.c	1999/08/09 21:33:34	1.1.1.3
+++ infptrace.c	1999/10/29 22:10:41
@@ -40,6 +40,10 @@
 #include <ptrace.h>
 #else
 #ifdef HAVE_SYS_PTRACE_H
+#undef PTRACE_GETREGS
+#undef PTRACE_SETREGS
+#undef PTRACE_GETFPREGS
+#undef PTRACE_SETFPREGS
 #include <sys/ptrace.h>
 #endif
 #endif
Index: sparc-nat.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 sparc-nat.c
- --- sparc-nat.c	1999/10/05 23:08:51	1.1.1.3
+++ sparc-nat.c	1999/10/29 22:10:43
@@ -24,6 +24,10 @@
 #include "gdbcore.h"
 
 #include <signal.h>
+#undef PTRACE_GETREGS
+#undef PTRACE_SETREGS
+#undef PTRACE_GETFPREGS
+#undef PTRACE_SETFPREGS
 #include <sys/ptrace.h>
 #include <sys/wait.h>
 #ifdef __linux__
Index: config/sparc/linux.mh
===================================================================
RCS file: /cvs/gdb/gdb/gdb/config/sparc/linux.mh,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 linux.mh
- --- linux.mh	1999/04/16 01:34:25	1.1.1.1
+++ linux.mh	1999/10/29 22:10:43
@@ -2,6 +2,6 @@
 XDEPFILES= ser-tcp.o
 XM_FILE= xm-linux.h
 NAT_FILE= nm-linux.h
- -NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o
+NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o linux-thread.o
 HOST_IPC=-DBSD_IPC
 GDBSERVER_DEPFILES= low-sparc.o
Index: config/sparc/nm-linux.h
===================================================================
RCS file: /cvs/gdb/gdb/gdb/config/sparc/nm-linux.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 nm-linux.h
- --- nm-linux.h	1999/07/07 20:17:01	1.1.1.2
+++ nm-linux.h	1999/10/29 22:10:43
@@ -30,3 +30,22 @@ extern int kernel_u_size PARAMS ((void))
 
 /* Linux is svr4ish but not that much */
 #undef USE_PROC_FS
+
+/* Support for the glibc linuxthreads package. */
+
+#ifdef __STDC__
+struct objfile;
+#endif
+
+extern void
+linuxthreads_new_objfile PARAMS ((struct objfile *objfile));
+#define target_new_objfile(OBJFILE) linuxthreads_new_objfile (OBJFILE)
+     
+extern char *
+linuxthreads_pid_to_str PARAMS ((int pid));
+#define target_pid_to_str(PID) linuxthreads_pid_to_str (PID)
+
+extern int
+linuxthreads_prepare_to_proceed PARAMS ((int step));
+#define PREPARE_TO_PROCEED(select_it) linuxthreads_prepare_to_proceed (1)
+
Index: config/sparc/tm-linux.h
===================================================================
RCS file: /cvs/gdb/gdb/gdb/config/sparc/tm-linux.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 tm-linux.h
- --- tm-linux.h	1999/07/07 20:17:06	1.1.1.2
+++ tm-linux.h	1999/10/29 22:10:43
@@ -21,6 +21,19 @@
 #ifndef TM_SPARCLINUX_H
 #define TM_SPARCLINUX_H
 
+/* Some versions of Linux have real-time signal support in the C library, and
+   some don't.  We have to include this file to find out.  */
+#include <signal.h>
+
+#ifdef __SIGRTMIN
+#define REALTIME_LO __SIGRTMIN
+#define REALTIME_HI (__SIGRTMAX + 1)
+#else
+#define REALTIME_LO 32
+#define REALTIME_HI 64
+#endif
+
+
 #include "sparc/tm-sparc.h"
 
 #define SIGCONTEXT_PC_OFFSET 12
------- End of forwarded message -------
From jimb@cygnus.com Mon Nov 01 07:17:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: muller@cerbere.u-strasbg.fr
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: print_symbol_info  patch for source code not current   language
Date: Mon, 01 Nov 1999 07:17:00 -0000
Message-id: <nphfj6kzs2.fsf@zwingli.cygnus.com>
References: <381824BF.BCE63370@cygnus.com> <5mogdjbkr2.fsf@jtc.redbacknetworks.com> <199910291101.NAA00678@cerbere.u-strasbg.fr> <npzox2klaw.fsf@zwingli.cygnus.com> <3.0.6.32.19991029232856.0089fdc0@ics.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00124.html
Content-length: 687

> >> However, saving, setting, and restoring the current language is
> >> somewhat messy.  Note that the definition of type_print just calls
> >> LA_PRINT_TYPE, which calls current_language->la_print_type.  Your code
> >> could simply determine the appropriate language, L, and then call
> >> L->la_print_type directly, instead of print_type.
> >
> >Sounds like a good idea.
> 
> That was my first try but its not a good solution because then you
> get the args output in current_language different from the function
> layout itself !!!

I'm sorry, I don't understand what you mean.  Could you show me an
example?  (A fake example is okay; I just want to see what you're
talking about.)
From jimb@cygnus.com Mon Nov 01 07:25:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 07:25:00 -0000
Message-id: <npg0yqkzes.fsf@zwingli.cygnus.com>
References: <199911010048.TAA07679@devserv.devel.redhat.com>
X-SW-Source: 1999-q4/msg00125.html
Content-length: 1079

What are these changes for?

> Index: infptrace.c
> ===================================================================
> RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v
> retrieving revision 1.1.1.3
> diff -u -p -r1.1.1.3 infptrace.c
> - --- infptrace.c	1999/08/09 21:33:34	1.1.1.3
> +++ infptrace.c	1999/10/29 22:10:41
> @@ -40,6 +40,10 @@
>  #include <ptrace.h>
>  #else
>  #ifdef HAVE_SYS_PTRACE_H
> +#undef PTRACE_GETREGS
> +#undef PTRACE_SETREGS
> +#undef PTRACE_GETFPREGS
> +#undef PTRACE_SETFPREGS
>  #include <sys/ptrace.h>
>  #endif
>  #endif
> Index: sparc-nat.c
> ===================================================================
> RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v
> retrieving revision 1.1.1.3
> diff -u -p -r1.1.1.3 sparc-nat.c
> - --- sparc-nat.c	1999/10/05 23:08:51	1.1.1.3
> +++ sparc-nat.c	1999/10/29 22:10:43
> @@ -24,6 +24,10 @@
>  #include "gdbcore.h"
>  
>  #include <signal.h>
> +#undef PTRACE_GETREGS
> +#undef PTRACE_SETREGS
> +#undef PTRACE_GETFPREGS
> +#undef PTRACE_SETFPREGS
>  #include <sys/ptrace.h>
>  #include <sys/wait.h>
>  #ifdef __linux__
From hjl@lucon.org Mon Nov 01 08:14:00 1999
From: hjl@lucon.org (H.J. Lu)
To: kingdon@redhat.com (Jim Kingdon)
Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 08:14:00 -0000
Message-id: <19991101161449.373C51B493@ocean.lucon.org>
References: <199911010048.TAA07679@devserv.devel.redhat.com>
X-SW-Source: 1999-q4/msg00126.html
Content-length: 413

> 
> The following looks OK to me (well, I haven't looked into the ptrace
> header lossage stuff but I can tell you we are shipping a similar
> patch).
> 

May I suggest to hold any Linuxthreads patches for the time being?
I have a patch which will make most of them obsolete. I will send
a patch after the i387 issue is resolved. I don't want to add more
to the backlog of Linux related patches.

Thanks.


H.J.
From jimb@cygnus.com Mon Nov 01 08:18:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg03: (buildsym|language).[ch]
Date: Mon, 01 Nov 1999 08:18:00 -0000
Message-id: <npd7tukxg1.fsf@zwingli.cygnus.com>
References: <Pine.LNX.4.10.9910291536290.17146-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00127.html
Content-length: 2063

Thanks!  I have some questions, though:

> + 1999-10-29	Jimmy Guo	<guo@cup.hp.com>
> + 
> + 	* buildsym.h (free_pendings): Declare.
> + 
> + 	* buildsym.c: Make free_pendings global, and misc. fixes.
> + 	(make_blockvector): 32x64 fix using longest_local_hex_string().
> + 	(start_subfile): initialize variable 'subfile'.
> + 	(end_symtab): fix bug freeing 'subfiles' list element, when it's
> + 	the list head to be freed.

...

> *** gdb/buildsym.h
> --- gdb/buildsym.h	Thu Oct 28 18:11:31 1999
> ***************
> *** 109,114 ****
> --- 109,118 ----
>       struct symbol *symbol[PENDINGSIZE];
>     };
>   
> + /* List of free `struct pending' structures for reuse.  */
> + 
> + EXTERN struct pending *free_pendings;
> + 
>   /* Here are the three lists that symbols are put on.  */
>   
>   /* static at top level, and types */

What are you planning to do with free_pendings elsewhere in GDB?

If you make a variable externally visible, that opens it up for
arbitrary use anywhere else in GDB.  People will see that extern
declaration and figure it's okay to do whatever they please.

Depending on what the other code needs to do, it might be better
instead to export a function from buildsym.c that does one specific
operation on free_pendings.  That way, it's easier for someone reading
buildsym.c to see what kind of interactions to expect from outside.


> ***************
> *** 998,1003 ****
> --- 991,998 ----
>   	}
>   
>         nextsub = subfile->next;
> +       if (subfiles == subfile)
> + 	subfiles = nextsub;
>         free ((void *) subfile);
>       }
>   

Could you explain this change a little more?  I understand that the
list of subfiles is being freed here, so without this, subfiles ends
up being a dangling pointer.  But it looks to me like the loop frees
the entire list of subfiles.  So subfiles will always end up being
zero.  And it doesn't look to me like subfiles is ever used while the
loop is running.

So, who is attempting to use subfiles after calling end_symtab without
calling start_symtab first to reinitialize things?
From robertl@sco.com Mon Nov 01 09:06:00 1999
From: Robert Lipe <robertl@sco.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 09:06:00 -0000
Message-id: <19991101110509.O19769@rjlhome.sco.com>
References: <199911010048.TAA07679@devserv.devel.redhat.com> <npg0yqkzes.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00128.html
Content-length: 1604

Jim Blandy wrote:

> What are these changes for?

These are unrelated to the Sparc/threads issue and were, in fact,
included quite by mistake. :-)

I know this is absolutely the wrong way to "fix" this problem, but if
the moral equivalent of this isn't done, RH6 on Sparc will not build GDB
becuase it gets all tangled up in the code that redefines PTRACE_*REGS
code.

From what I recall, sys/ptrace.h and one of the GDB headers were each
trying to outsmart the other.   

RJL


> 
> > Index: infptrace.c
> > ===================================================================
> > RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v
> > retrieving revision 1.1.1.3
> > diff -u -p -r1.1.1.3 infptrace.c
> > - --- infptrace.c	1999/08/09 21:33:34	1.1.1.3
> > +++ infptrace.c	1999/10/29 22:10:41
> > @@ -40,6 +40,10 @@
> >  #include <ptrace.h>
> >  #else
> >  #ifdef HAVE_SYS_PTRACE_H
> > +#undef PTRACE_GETREGS
> > +#undef PTRACE_SETREGS
> > +#undef PTRACE_GETFPREGS
> > +#undef PTRACE_SETFPREGS
> >  #include <sys/ptrace.h>
> >  #endif
> >  #endif
> > Index: sparc-nat.c
> > ===================================================================
> > RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v
> > retrieving revision 1.1.1.3
> > diff -u -p -r1.1.1.3 sparc-nat.c
> > - --- sparc-nat.c	1999/10/05 23:08:51	1.1.1.3
> > +++ sparc-nat.c	1999/10/29 22:10:43
> > @@ -24,6 +24,10 @@
> >  #include "gdbcore.h"
> >  
> >  #include <signal.h>
> > +#undef PTRACE_GETREGS
> > +#undef PTRACE_SETREGS
> > +#undef PTRACE_GETFPREGS
> > +#undef PTRACE_SETFPREGS
> >  #include <sys/ptrace.h>
> >  #include <sys/wait.h>
> >  #ifdef __linux__
From robertl@sco.com Mon Nov 01 09:13:00 1999
From: Robert Lipe <robertl@sco.com>
To: "H.J. Lu" <hjl@lucon.org>
Cc: Jim Kingdon <kingdon@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 09:13:00 -0000
Message-id: <19991101111145.P19769@rjlhome.sco.com>
References: <199911010048.TAA07679@devserv.devel.redhat.com> <19991101161449.373C51B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00129.html
Content-length: 718

H.J. Lu wrote:

> May I suggest to hold any Linuxthreads patches for the time being?

Fine with me.  I'm certainly not in a position to argue strongly for
them.

> I have a patch which will make most of them obsolete. I will send
> a patch after the i387 issue is resolved. I don't want to add more
> to the backlog of Linux related patches.

I would very much like to see something settle down that would benefit
the users of GDB and threads on non-IA32 systems as well.  I'm sure
that the needs of the many (Linux/IA32) outweigh the needs of the
few (Linux/everything else) but if this could be worked out in a
Linux-dependent manner instead of a Linux/IA32-dependent manner, that
would be most helpful.

Thanx,
RJL
From hjl@lucon.org Mon Nov 01 09:19:00 1999
From: hjl@lucon.org (H.J. Lu)
To: robertl@sco.com (Robert Lipe)
Cc: hjl@lucon.org (H.J. Lu), kingdon@redhat.com (Jim Kingdon), gdb-patches@sourceware.cygnus.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 09:19:00 -0000
Message-id: <19991101171955.2EFD11B493@ocean.lucon.org>
References: <19991101111145.P19769@rjlhome.sco.com>
X-SW-Source: 1999-q4/msg00130.html
Content-length: 718

> 
> I would very much like to see something settle down that would benefit
> the users of GDB and threads on non-IA32 systems as well.  I'm sure
> that the needs of the many (Linux/IA32) outweigh the needs of the
> few (Linux/everything else) but if this could be worked out in a
> Linux-dependent manner instead of a Linux/IA32-dependent manner, that
> would be most helpful.
> 

My next Linuxthreads patch will make it arch-independent. That is how
gdb 4.17.0.14 works on ia32, alpha and ppc. I only needed to modify
less than 10 lines to make Linuxthreads work on alpha and ppc. It is
very trivial. My guess is Jim used an older gdb 4.17.0.xx for the
Linuxthreads support in gdb 4.19. 


-- 
H.J. Lu (hjl@gnu.org)
From kingdon@redhat.com Mon Nov 01 09:42:00 1999
From: Jim Kingdon <kingdon@redhat.com>
To: robertl@sco.com
Cc: davem@redhat.com, jakub@redhat.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 09:42:00 -0000
Message-id: <199911011742.MAA28800@devserv.devel.redhat.com>
References: <199911010048.TAA07679@devserv.devel.redhat.com> <npg0yqkzes.fsf@zwingli.cygnus.com> <19991101110509.O19769@rjlhome.sco.com>
X-SW-Source: 1999-q4/msg00131.html
Content-length: 1694

> From what I recall, sys/ptrace.h and one of the GDB headers were each
> trying to outsmart the other.

No, it is two system headers.  /usr/include/asm-sparc/ptrace.h
(included via a dizzying cascade of includes from
/usr/include/signal.h) and /usr/include/sys/ptrace.h.  The former
contains "#define PTRACE_GETREGS 12" and the latter has an enum which
contains "PTRACE_GETREGS = 12".

DaveM, Jakub, let's get this fixed.  We've been kludging around it in
GDB long enough.

(Something along these lines is also gdb-4.18-sparcmin.patch in any
recent Red Hat RPM for GDB)

> > Index: infptrace.c
> > ===================================================================
> > RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v
> > retrieving revision 1.1.1.3
> > diff -u -p -r1.1.1.3 infptrace.c
> > - --- infptrace.c	1999/08/09 21:33:34	1.1.1.3
> > +++ infptrace.c	1999/10/29 22:10:41
> > @@ -40,6 +40,10 @@
> >  #include <ptrace.h>
> >  #else
> >  #ifdef HAVE_SYS_PTRACE_H
> > +#undef PTRACE_GETREGS
> > +#undef PTRACE_SETREGS
> > +#undef PTRACE_GETFPREGS
> > +#undef PTRACE_SETFPREGS
> >  #include <sys/ptrace.h>
> >  #endif
> >  #endif
> > Index: sparc-nat.c
> > ===================================================================
> > RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v
> > retrieving revision 1.1.1.3
> > diff -u -p -r1.1.1.3 sparc-nat.c
> > - --- sparc-nat.c	1999/10/05 23:08:51	1.1.1.3
> > +++ sparc-nat.c	1999/10/29 22:10:43
> > @@ -24,6 +24,10 @@
> >  #include "gdbcore.h"
> >  
> >  #include <signal.h>
> > +#undef PTRACE_GETREGS
> > +#undef PTRACE_SETREGS
> > +#undef PTRACE_GETFPREGS
> > +#undef PTRACE_SETFPREGS
> >  #include <sys/ptrace.h>
> >  #include <sys/wait.h>
> >  #ifdef __linux__
From kingdon@redhat.com Mon Nov 01 10:07:00 1999
From: Jim Kingdon <kingdon@redhat.com>
To: hjl@lucon.org
Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 10:07:00 -0000
Message-id: <199911011806.NAA29518@devserv.devel.redhat.com>
References: <19991101161449.373C51B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00132.html
Content-length: 810

> May I suggest to hold any Linuxthreads patches for the time being?
> I have a patch which will make most of them obsolete. I will send
> a patch after the i387 issue is resolved. I don't want to add more
> to the backlog of Linux related patches.

I don't see any reason why threads should need to wait until after
387.

A patch in the hand is worth two in the bush (Cygnus also has quite a
few threads patches/rewrites in the bush, which sound good from what
I've heard, but I'm not putting off all thread work until they show
up).  If people want to make the threads configuration stuff
arch-independent (which I agree is the clean solution), that's OK.
But if no patch to do so is forthcoming, I'd vote for checking in
robertl's sparc patch (minus the ptrace header kludges) until this can
be done right.
From robertl@sco.com Mon Nov 01 10:10:00 1999
From: Robert Lipe <robertl@sco.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: jimb@cygnus.com, gdb-patches@sourceware.cygnus.com, davem@redhat.com, jakub@redhat.com
Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB]
Date: Mon, 01 Nov 1999 10:10:00 -0000
Message-id: <19991101120917.S19769@rjlhome.sco.com>
References: <199911010048.TAA07679@devserv.devel.redhat.com> <npg0yqkzes.fsf@zwingli.cygnus.com> <19991101110509.O19769@rjlhome.sco.com> <199911011742.MAA28800@devserv.devel.redhat.com>
X-SW-Source: 1999-q4/msg00133.html
Content-length: 617

> > From what I recall, sys/ptrace.h and one of the GDB headers were
> > each trying to outsmart the other.
>
> No, it is two system headers. /usr/include/asm-sparc/ptrace.h
> (included via a dizzying cascade of includes from
> /usr/include/signal.h) and /usr/include/sys/ptrace.h.  The former
> contains "#define PTRACE_GETREGS 12" and the latter has an enum which
> contains "PTRACE_GETREGS = 12".

Yes, that does definitely sound familar now that you mention it.  This
has been in my local tree for several months, so I had forgotten the
details.  Only by looking at the cpp output does it become "obvious".


RJL
From guo@cup.hp.com Mon Nov 01 10:26:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg03: (buildsym|language).[ch]
Date: Mon, 01 Nov 1999 10:26:00 -0000
Message-id: <Pine.LNX.4.10.9911010939010.16929-100000@hpcll168.cup.hp.com>
References: <npd7tukxg1.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00134.html
Content-length: 2408

>What are you planning to do with free_pendings elsewhere in GDB?
>
>If you make a variable externally visible, that opens it up for
>arbitrary use anywhere else in GDB.  People will see that extern
>declaration and figure it's okay to do whatever they please.
>
>Depending on what the other code needs to do, it might be better
>instead to export a function from buildsym.c that does one specific
>operation on free_pendings.  That way, it's easier for someone reading
>buildsym.c to see what kind of interactions to expect from outside.

The other code (hp-symtab-read.c (hpread_read_function_type)) uses a
'local_list' to add fparam to.  If the routine is called just to get the
function type (instead of for creating a new block), this local_list
does not get 'freed', but should be.  Looking at the code again I agree
that the free_pendings list should probably stay local and let a
specific function to manage additions to the list.  I will revise the
patch to reflect your input!

>>         nextsub = subfile->next;
>> +       if (subfiles == subfile)
>> + 	subfiles = nextsub;
>>         free ((void *) subfile);
>>       }
>>   
>
>Could you explain this change a little more?  I understand that the
>list of subfiles is being freed here, so without this, subfiles ends
>up being a dangling pointer.  But it looks to me like the loop frees
>the entire list of subfiles.  So subfiles will always end up being
>zero.  And it doesn't look to me like subfiles is ever used while the
>loop is running.
>
>So, who is attempting to use subfiles after calling end_symtab without
>calling start_symtab first to reinitialize things?

Good question.  The fix was related to a HP-UX 11.0 test failure about a
year ago, related to HP aCC support.  Since 1) the test involved is no
longer available (duh) 2) there are tons of failures right now with
Cygnus GDB when it comes to HP aCC support, I'm going to postpone
merging this particular piece of code until we are at a stage where I
can be better positioned to triage a failure that could be related to
this to provide a real answer :)  For now, I think this change is nice
to have (although I'd just put in a 'subfiles = NULL' after the loop
instead), but could shadow a real problem / issue somewhere else where
subfiles is referenced after end_symtab().

Stay tuned for a revision of the patch.  Thanks for the comments, Jim!

- Jimmy Guo, guo@cup.hp.com