Forward from GNU volunteer coordination

Forward from GNU volunteer coordination

[S. Morningthunder]

This individual is interested in the GDB to Guile interface.

------- Start of forwarded message -------
Date: Sat, 23 Jan 1999 02:24:45 -0200 (GMT)
From: Rubens Ramos Fernandes Junior <rubens_ramos@yahoo.com>
To: gvc@gnu.org
Subject: GDB/Scheme

Hello,

 I have sent an email with root@hal2001.ddns.org sender in it.
 You can disconsider that.

 But I still want to work on GDB. If you could tell me what to
 do next, I'd appreciate very much

Thanks
Rubens Ramos
------- End of forwarded message -------

Forward from GNU volunteer coordination

[S. Morningthunder]

This individual is interested in the GDB to Guile interface.

------- Start of forwarded message -------
Date: Sat, 23 Jan 1999 02:24:45 -0200 (GMT)
From: Rubens Ramos Fernandes Junior <rubens_ramos@yahoo.com>
To: gvc@gnu.org
Subject: GDB/Scheme

Hello,

 I have sent an email with root@hal2001.ddns.org sender in it.
 You can disconsider that.

 But I still want to work on GDB. If you could tell me what to
 do next, I'd appreciate very much

Thanks
Rubens Ramos
------- End of forwarded message -------

Forward from GNU volunteer coordination

[S. Morningthunder]

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

Forward from GNU volunteer coordination

[S. Morningthunder]

This man wants to work on GDB.

------- Start of forwarded message -------
Resent-From: Project GNU <gnu@gnu.org>
Resent-To: gvc@gnu.org
Date: Mon, 6 Sep 1999 18:08:40 +0200
From: JAVIER RODENAS GARCIA <jrodena@bugs.eleinf.uv.es>
To: gnu@gnu.org
Subject: About improving GDB

Hello:
	First, I'm sorry for my english, it's not good. I'm a student of
Informatic Engineer and I'm going to finish it next month. I would like
to work on improving GDB for making program's profiles.
	So, I has been reading your Web pages about how to help GNU and I
need more information. I need to know if I can modify GDB and, if I
can, what should I do to give other people the modifications.
	Please, if you can, answer me for knowing what shoul I do.
			Thank you very much.

P.S.: I have problems with my e-mail. You can answer me to the following
address:
		jrodena@bugs.eleinf.uv.es
		jrodena@slabii.eleinf.uv.es
						Thanks.
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

mthunder@gnu.org

Forward from GNU volunteer coordination

[S. Morningthunder]

This man is potentially interested in improving gdb.


------- Start of forwarded message -------
From: "Randy Wolf" <rwolf@worldisp1.net>
To: <gvc@gnu.org>
Subject: restart capability in gdb?
Date: Fri, 15 Jan 1999 11:05:36 -0600

I'm interested in being able to capture a running process image,
storing it, and restarting it.  Your gdb debugger doesn't seem to
support this.  If that is an incorrect assessment, then I would
appreciate your telling me how this works.  The dbx debugger on SUN's
did have a 'restart' command if I recall correctly.

If I am correct in thinking that gdb doesn't allow process
saving/restart, then I might possibly be interested in working on
adding that capability to gdb.  I would need to know more details
about how that would work. An estimate from someone familiar with gdb
about how hard it would be to do would be something I would want to
know.

Thanks

Dr. Randy P. Wolf
1006 Woods Cove Rd
Scottsboro, AL 35768
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

mthunder@gnu.org

Forward from GNU volunteer coordination

[S. Morningthunder]

This man is potentially interested in improving gdb.


------- Start of forwarded message -------
From: "Randy Wolf" <rwolf@worldisp1.net>
To: <gvc@gnu.org>
Subject: restart capability in gdb?
Date: Fri, 15 Jan 1999 11:05:36 -0600

I'm interested in being able to capture a running process image,
storing it, and restarting it.  Your gdb debugger doesn't seem to
support this.  If that is an incorrect assessment, then I would
appreciate your telling me how this works.  The dbx debugger on SUN's
did have a 'restart' command if I recall correctly.

If I am correct in thinking that gdb doesn't allow process
saving/restart, then I might possibly be interested in working on
adding that capability to gdb.  I would need to know more details
about how that would work. An estimate from someone familiar with gdb
about how hard it would be to do would be something I would want to
know.

Thanks

Dr. Randy P. Wolf
1006 Woods Cove Rd
Scottsboro, AL 35768
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

mthunder@gnu.org

Forward from GNU volunteer coordination

[S. Morningthunder]

This man is interested in the over-the-ethernet debugger stub for GDB.


------- Start of forwarded message -------
Resent-From: gnu@gnu.org
Resent-To: gvc@gnu.org
Date: Wed, 18 Mar 1998 17:58:12 +0530
From: Manu <manu@npi.stpn.soft.net>
To: gnu@gnu.org
Subject: Writing software for GNU

Hello,
I visited your web site which contained a small enumeration of projects
which would require contribution in writing s/w for GNU.
I am interested in working for the following project :

"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 would like to get some further detailed information about this
project. I am a s/w engineer with about two years of industry experience
at different locations (US, Japan and India). I am presently working in
India and u may get in touch with me at "manu@npi.stpn.soft.net".

Hope to hear from you soon
regards
Manu
------- End of forwarded message -------

Re: Forward from GNU volunteer coordination

[Greg McGary]

> ... 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.

I've done UDP stubs for embedded systems.  Standalone UDP is quite
serviceable and much easier to implement than TCP and has the
advantage of being useable across IP internets, whereas a custom
direct-ethernet protocol would not.

Forward from GNU Volunteer Coordination

[S. Morningthunder]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

This individual may be interested in contributing to development of
GDB.  I did _not_ give out your address.

Thanks much.
------- Start of forwarded message -------
Resent-From: gnu@gnu.org
Resent-To: gvc@gnu.org
Date: Fri, 27 Feb 1998 10:17:27 -0700
From: Tom Hall <thall@fujin.intellistor.com>
To: gnu@gnu.org
Subject: questions for GDB developers
Reply-To: thall@Intellistor.COM
Organization: Intellistor R&D Operation
Phone: (303) 682-6544
Operating-System: SunOS fujin 4.1.4

I would like to asks some questions of the developers of GDB.

In particular, I see that GDB has some support for languages other that C
and C++ - from browsing around it looks like it has some support for
Modula-2, Pascel, Chill, etc.  I would like to assess what it would
take to add support for FreeHDL.

If you could give me an email address of a GDB developer, or point me to
"the GDB Home Page" (which I can't find - can't even find GDB on
www.gnu.org ?), I'd appreciate it.

Thanks.
Tom Hall
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

Instituto de Física, Universidad Nacional Autónoma de México
mthunder@gnu.org
mthunder@jreyes.ifisicacu.unam.mx

Forward from GNU volunteer coordination

[S. Morningthunder]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]

I don't know whether this will be of any use to you or not.  But it
seems like a logical place to begin.


------- Start of forwarded message -------
Resent-From: GNU Mailing List Maintenance <gnu@prep.ai.mit.edu>
Date: Wed, 26 Nov 1997 23:59:46 -0800
From: Pascal Martin <pmartin@earthlink.net>
To: gnu@prep.ai.mit.edu
Subject: over-the-ethernet debug stub
Resent-To: gvc@prep.ai.mit.edu

Hello.

I have seen on your WEB pages a request for help for this project.

Although I would have enjoyed volunteering, I currently have no time
available.

I do, however, have some experience on that subject, having designed
and implemented a very similar debugger stub in a previous job.
Here are some comments about your description of the project.

It appears to me that such an Ethernet support would be an invaluable
addition to the embedded environment support in GNU, so the stub
should be designed for reuse ouside the HURD itself.

- - protocols to be used.

  My experience is that it is always a bad idea to not use the
  Internet protocol suite, because most systems protect the low
  level Ethernet socket for obvious security reasons. Also, using
  the Internet suite is much more portable (including Windows 95/NT).

  I had developped a small UDP/IP suite which, compiled, took
  about 7 Kbytes of 68k code, despite the fact it was Ada sources.
  This implementation included ARP/RARP and ICMP/ECHO support,
  plus an auto-configuring routing table:

  * ARP/RARP is obviously a must-have and more recent alternatives
    are quite memory-hungry.
  * Having ping to work has been proven very useful.
  * The routing support made me able to debug a target in France
    from my workstation in San Diego (how fun !).

  In other words, UDP/IP is perfectly suitable for this project.

  Of course, UDP/IP packets may be lost, so each command must have
  a sequence number, the workstation must retry commands when it
  receives no answer (timeout), and give up after n retry (except
  may be after a "go" command, because you never know how long it
  will take..).

  The target side must reply to all commands, but must execute
  a command only once and be able to repeat its last reply. This
  involves at most a mere 1.5Kbytes of data (one Ethernet packet).

  A variant of the existing gdb remote debugging protocol is
  probably usable: just add a header to contains the sequence
  number. In any case, avoid double acknowledgment as I have seen
  in some product: the UDP packet was acknowledged, then the
  answer packet was sent (and acknowledged..). This was an artifact
  of reusing a protocol designed for RS232 lines, and this was really
  inefficient, and even less reliable.

- - Ethernet sharing.

  What have been a major problem is to share the Ethernet access
  between the debugger and the applications. An acceptable solution
  was to let the debugger peek at each network packet received, so it
  can intercept debugger's commands when the application is running
  (so the debugger can do dumps or stop the application).

- - auto-configured routing support.

  A target is always a server that answers to a debugger requests.
  That means a target always receives a packet from the workstation
  before it sends one of its own.

  Because of that it knows the _Ethernet_ address of the source.

  There are two cases:

  - the workstation is local. The Ethernet address is the address
    of the workstation. There is no need to issue an ARP request:
    we can fill the ARP table right now.

  - the workstation is on a remote network. The Ethernet address is
    then always the address of a router. Because Internet routes are
    almost always bi-directional, sending the answer packet to that
    router will initiate a successful routing trip to the workstation.

    It is then safe to associate the workstation's IP address with
    the _router_ Ethernet address.

  Conclusion: any valid debugger UDP/IP packet received can be used
  to blindly initialize an ARP cache entry. This is totally automatic,
  there is absolutely no configuration required, and there is not even
  really any routing code involved.

  .. and I never took any patent on this one, so I guess you can use
  it without any fear of being sued.


I hope this may help some day..

Regards,
Pascal MARTIN.
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

Instituto de Física, Universidad Nacional Autónoma de México
mthunder@gnu.org
mthunder@jreyes.ifisicacu.unam.mx