Re: Moving Linux-specific stuff out of i386-tdep.c

Re: Moving Linux-specific stuff out of i386-tdep.c

[Mark Kettenis]

   Date: Fri, 10 Mar 2000 01:05:59 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Mark Kettenis wrote:

   > 2. Should I postpone creating the new -tdep.c file until after the
   >    release or not.  Andrew has been telling us to avoid gratuitous
   >    changes to make it easier to apply outstanding patches.  But on the
   >    other hand, after 5.0 is released, I hope to see a lot new patches
   >    generated against 5.0.  So creating the new file before 5.0 would
   >    make applying those new patches a lot easier.

   I guess its the sigtramp stuff.

Indeed.

   If the checkin was a straight cut/paste (without edits) I won't notice
   :-)
   Down the track, there will need to be ``i386-linux-tdep.h'' so that
   i386-linux-nat.c can include it.  (Hmm, with i386-linux-tdep.c, no
   wonder Eli raised a concern).

The 8.3 limit really prevents me from choosing a sensible name here.
So I'll leave the Linux code in i386-tdep.c for now.  If we ever come
up with a sensible way to reorganize the GDB sources we can reconsider
things.

Mark
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091211.HAA19860@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org>
X-SW-Source: 2000-q1/msg00636.html
Content-length: 1704

Problem no.2: Read watchpoints break when they shouldn't.

Example (slightly modified test program posted by H.J. Lu):

$ cat wp.c
int a1;
int a2;
int a3;
int a4;
int a5;
int a6;

unsigned long long ulla1 = 0;
double da2 = 0;

int main (void)
{
  a2 = 12;
  a3 = 13;
  a4 = 14;
  a5 = 15;
  a6 = 16;
  a1 = 11;
  a2 = a4;

  ulla1 = 0x00000000ffffffffLL;
  da2 = 12;
  ulla1 = 0xffffffff00000000LL;

  return 0;
}

$ gcc -g -o wp wp.c
$ gdb wp
(gdb) watch a5
Hardware watchpoint 2: a5
(gdb) rwatch a5
Hardware read watchpoint 3: a5
(gdb) run
Starting program g:/gdbsnap/gdb-0222/gdb/wp
Hardware watchpoint 2: a5

Old value = 0
New value = 15
Hardware read watchpoint 3: a5

Value = 15
main () at wp.c: 16
16	a5 = 15;
(gdb)

Now, it might seem like a strange idea to put two watchpoints on the
same variable, but it is a very useful feature when each watchpoint
has a different condition.

Here's the patch:

2000-03-08  Eli Zaretskii  <eliz@is.elta.co.il>

	* breakpoint.c (bpstat_stop_status): Don't stop if a read
	watchpoint appears to break, but the watched value changed.


--- gdb/breakpoint.c~2	Wed Mar  8 19:20:28 2000
+++ gdb/breakpoint.c	Wed Mar  8 20:02:20 2000
@@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
 	      /* Stop.  */
 	      break;
 	    case WP_VALUE_CHANGED:
+	      if (b->type == bp_read_watchpoint)
+		{
+		  /* Don't stop: read watchpoints shouldn't fire if
+		     the value has changed.  This is for targets which
+		     cannot set read-only watchpoints.  */
+		  bs->print_it = print_it_noop;
+		  bs->stop = 0;
+		  continue;
+		}
+	      ++(b->hit_count);
+	      break;
 	    case WP_VALUE_NOT_CHANGED:
 	      /* Stop.  */
 	      ++(b->hit_count);
From Timo.Ketola@Epec.fi Sat Apr 01 00:00:00 2000
From: Timo Ketola <Timo.Ketola@Epec.fi>
To: gdb@sourceware.cygnus.com
Subject: Remote Debugging
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B4017A.2F64A9C3@Epec.fi>
X-SW-Source: 2000-q1/msg00382.html
Content-length: 984

Hi all,

I just subscribed to this list...

I'm adapting the gdb and the remote stub for our embedded system.
Debugging works already over a RS232 line but I have a couple of
questions for which I can't find an answer:

1) I want to be able to debug also over a CAN network. I think I have to
write a new interface for the gdb. Namely the getpkt and putpkt of the
remote.c should be reimplemented. But what is a clean way? Could someone
assist me a bit.

2) When I 'load' a new executable into the target the loading works well
but the symbols are not loaded. At the end of generic_load function
comment asks whether symbol_file_add function should be called. Is that
exactly the right thing to do?

3) How do I get a clean information about the load of the new executable
in the stub? Before a new executable is started (or an old one
restarted) the stub needs to do a couple of things (for example clean up
the stack).

Please, forgive me if the answers are too obvious...
--
Timo

Re: Moving Linux-specific stuff out of i386-tdep.c

[Andrew Cagney]

Mark Kettenis wrote:

> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.

Per other e-mail: no but (8.3 :-)

> 2. Should I postpone creating the new -tdep.c file until after the
>    release or not.  Andrew has been telling us to avoid gratuitous
>    changes to make it easier to apply outstanding patches.  But on the
>    other hand, after 5.0 is released, I hope to see a lot new patches
>    generated against 5.0.  So creating the new file before 5.0 would
>    make applying those new patches a lot easier.

I guess its the sigtramp stuff.

If the checkin was a straight cut/paste (without edits) I won't notice
:-)
Down the track, there will need to be ``i386-linux-tdep.h'' so that
i386-linux-nat.c can include it.  (Hmm, with i386-linux-tdep.c, no
wonder Eli raised a concern).

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Benjamin Kosnik <bkoz@cygnus.com.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: --target=powerpc-elf broken in current sources?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A8A385.24864EC4@cygnus.com>
References: <200002150036.QAA14529@haight.constant.com>
X-SW-Source: 2000-q1/msg00273.html
Content-length: 346

Benjamin Kosnik wrote:
> 
> configuring a cross compiler on x86-linux for powerpc-elf, I get this:
> 

> ../../../src.gdb_binutils_orig/sim/ppc/mon.c:273: `RUSAGE_SELF' undeclared (first use in this function)

> ??

That sounds like a problem specific to a particular version of linux. 
Have you tried a build on an older linux release?

	Andrew
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: arguments to add-symbol-file
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14554.48522.187490.733204@kwikemart.cygnus.com>
References: <14554.41686.732151.870885@kwikemart.cygnus.com> <1000324000053.ZM31438@ocotillo.lan>
X-SW-Source: 2000-q1/msg00785.html
Content-length: 1371

Kevin Buettner writes:
 > On Mar 23,  6:03pm, Elena Zannoni wrote:
 > 
 > > Why when we use 
 > > 
 > > add-symbol-file <file> 0x1000 0x2000 0x3000
 > > 
 > > gdb ends up with the following addrs structure, which includes explicit
 > > entries for .text, .data, and .bss section, plus the same 3 entries
 > > repeated in the 'other' array?
 > > 
 > > Would it make sense to have only the 'other' part, or not include
 > > those three in 'other'?
 > 
 > I think it'd make sense to only have the `other' part.
 > 
 > BTW, did you notice the following comment from symfile.h?
 > 
 >                 /* Add the section to the others even if it is a
 >                    text data or bss section. This is redundent but
 >                    eventually, none will be given special treatment */
 > 

And this one in symfile.c:
      /* FIXME: These sections will not need special treatment because ALL
	 sections are in the other sections table */

All the relevant code is structured like this:

 if ( this is .text )
	do something
 if ( this is .data )
	do something
 if ( this is .bss )
	do something
 for ( all in others )
        do something

Where 'something' is pretty much the same set of instructions. 

 > I think you should ask Fred about it.  (There's probably some reason
 > why it'll be non-trivial to fix.)
 > 

Yes, that's why I was puzzled. 

 > Kevin

Elena
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: "Daniel Berlin+list.gdb-patches" <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003232042220.12024-100000@hpcll168.cup.hp.com>
References: <hfdx6o2m.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00787.html
Content-length: 681

>Can someone verify, that i am correct in thinking you get unexpected
>failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
>I have a patch, i just want to make sure it's not me.
>It appears the source line the test suite expects main to appear on
>in that file is 49, and main really appears at 48, so the regex to
>match doesn't work.  I diffed the ovldbreak.cc file, and i get no
>differences.

I think it should report 49, not 48.  Line 49 is the first executable
statement of main.  I'm using the HP WDB source, in case you cannot see
such behavior with sourceware's (in that case I will spend some time
digging up the fix to submit as a patch).

- Jimmy Guo

14 chars limit [Was: Re: Moving Linux-specific stuff out of i386-tdep.c]

[Fernando Nasser]

Mark Kettenis wrote:
> 
> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.
> 

There are several files now with 14+ chars.  I am just about to add one (with 16).

Is this still relevant?

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307155806.A30106@valinux.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com>
X-SW-Source: 2000-q1/msg00572.html
Content-length: 6084

On Tue, Mar 07, 2000 at 02:42:02PM -0800, Stan Shebs wrote:
> "H . J . Lu" wrote:
> > 
> > I believe gnu-regex is maintained in glibc 2. I'd like to use the one
> > in glibc 2 instead of the one in gdb.
> 
> I don't know if there is any more elegant way to handle the linux.mh vs
> linuxlibc1.mh distinction (although we should try, instead of making
> still more file semi-clones), but you could simplify the source files by
> making a gdb_regex.h similar to the other gdb_*.h substitute files, and
> put the #if sequence in it.
> 

Here is a new patch.


-- 
H.J. Lu (hjl@gnu.org)
---
2000-03-07  H.J. Lu  <hjl@gnu.org>

	* gdb-regex.h: New. Include <regex.h> for glibc 2 and include
	"gnu-regex.h" otherwise.

        * irix5-nat.c: Include "gdb-regex.h" instead of "gnu-regex.h".
	* monitor.c: Likewise.
	* osfsolib.c: Likewise.
	* solib.c: Likewise.
	* source.c: Likewise.
	* symtab.c: Likewise.

	* Makefile.in (REGEX): Changed to @REGEX@.
	(REGEX1): Removed.
	(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).

	* configure.in (REGEX): New. Subsstitue @REGEX@ in Makefile.in.
	* configure: Regenerated.

Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in	2000/03/07 18:42:08	1.1.1.9
+++ Makefile.in	2000/03/07 23:28:45
@@ -285,8 +290,7 @@ HLDENV = @HLDENV@
 
 # We are using our own version of REGEX now to be consistent across
 # machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
+REGEX = @REGEX@
 
 # If your system is missing alloca(), or, more likely, it's there but
 # it doesn't work, then refer to libiberty.
@@ -308,7 +312,7 @@ CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CD
 	$(OPCODES) $(MMALLOC) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
 
 ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
-ADD_DEPS = $(REGEX1) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
+ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
 
 VERSION = 20000204
 DIST=gdb
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in	2000/03/07 18:42:10	1.1.1.6
+++ configure.in	2000/03/07 23:47:24
@@ -101,6 +101,24 @@ AC_C_CONST
 AC_CHECK_FUNCS(setpgid sbrk sigaction isascii bzero bcopy btowc poll sigprocmask)
 AC_FUNC_ALLOCA
 
+dnl See if we have GNU regex in glibc 2.
+AC_MSG_CHECKING(for GNU regex in glibc 2)
+AC_CACHE_VAL(gdb_cv_have_glibc_2,
+[AC_TRY_COMPILE([#include <features.h>],
+[#if !defined __GLIBC__ || __GLIBC__ < 2
+#error It is not glibc 2.
+#endif
+],
+		[gdb_cv_have_glibc_2=yes],
+		[gdb_cv_have_glibc_2=no])])
+AC_MSG_RESULT($gdb_cv_have_glibc_2)
+if test $gdb_cv_have_glibc_2 = yes; then
+  REGEX=
+else
+  REGEX="gnu-regex.o"
+fi
+AC_SUBST(REGEX)
+
 dnl See if ptrace.h provides the PTRACE_GETREGS request.
 AC_MSG_CHECKING(for PTRACE_GETREGS)
 AC_CACHE_VAL(gdb_cv_have_ptrace_getregs,
--- /dev/null	Tue May  5 13:32:27 1998
+++ gdb-regex.h	Tue Mar  7 15:47:50 2000
@@ -0,0 +1,7 @@
+#ifndef _GDB_REGEX_H
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
+#endif /* _GDB_REGEX_H */
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 irix5-nat.c
--- irix5-nat.c	1999/11/19 23:38:46	1.1.1.3
+++ irix5-nat.c	2000/03/07 23:24:47
@@ -278,7 +278,7 @@ fetch_core_registers (core_reg_sect, cor
 #include "objfiles.h"
 #include "command.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "language.h"
 #include "gdbcmd.h"
Index: monitor.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v
retrieving revision 1.1.1.5
diff -u -p -r1.1.1.5 monitor.c
--- monitor.c	2000/03/07 18:42:14	1.1.1.5
+++ monitor.c	2000/03/07 23:24:50
@@ -50,7 +50,7 @@
 #include "monitor.h"
 #include "gdbcmd.h"
 #include "inferior.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "dcache.h"
 #include "srec.h"
 
Index: osfsolib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 osfsolib.c
--- osfsolib.c	1999/11/19 23:38:50	1.1.1.3
+++ osfsolib.c	2000/03/07 23:24:55
@@ -36,7 +36,7 @@
 #include "command.h"
 #include "target.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "language.h"
 #include "gdbcmd.h"
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 solib.c
--- solib.c	2000/03/07 18:42:17	1.1.1.4
+++ solib.c	2000/03/07 23:25:01
@@ -49,7 +49,7 @@
 #include "command.h"
 #include "target.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "environ.h"
 #include "language.h"
Index: source.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/source.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 source.c
--- source.c	2000/02/04 20:21:58	1.1.1.3
+++ source.c	2000/03/07 23:25:07
@@ -33,7 +33,7 @@
 #include "gdb_stat.h"
 #include <fcntl.h>
 #include "gdbcore.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "symfile.h"
 #include "objfiles.h"
 #include "annotate.h"
Index: symtab.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 symtab.c
--- symtab.c	2000/03/07 18:42:17	1.1.1.4
+++ symtab.c	2000/03/07 23:25:15
@@ -30,7 +30,7 @@
 #include "objfiles.h"
 #include "gdbcmd.h"
 #include "call-cmds.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "expression.h"
 #include "language.h"
 #include "demangle.h"
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Hayes <m.hayes@elec.canterbury.ac.nz>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Cycle stepping
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4FC30.F3F69EBF@cygnus.com>
References: <14500.60988.450983.214268@ongaonga.elec.canterbury.ac.nz>
X-SW-Source: 2000-q1/msg00242.html
Content-length: 1118

Michael Hayes wrote:
> 
> I'm in the process of revitalising the tic4x target for submission.
> One big change that I've noticed is that a simulator can no longer use
> any of gdb's routines.
> 
> Now one useful feature we had with the c4x simulator was to provide
> single cycle stepping to observe the operation of the pipeline.  This
> was achieved by adding a couple of new commands to gdb's interpreter
> (stepc and nextc) whenever the c4x simulator was fired up.  Now in the
> process of making the c4x simulator stand-alone, does anyone know of a
> simple way that this functionality can be added to gdb?
> 
> Presently, stepc is similar to stepi but we use a flag to tell the
> simulator to stop after a cycle.  Is there a mechanism for
> communicating parameters like this to the simulator to avoid having to
> add another argument to target_resume?

You could table a proposal that ``step'' become an enum - run=0,
stepc=1, stepi=2.  Which would accomodate backward compatibility.

	Andrew

(Disclaimer - I've not thought this through and from memory you also
need a bit of serious WaitForInferior hacking).
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: Re: cvsup & sourceware repositories?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003162342590.8409-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00734.html
Content-length: 2789

<< added the missing command line I mentioned at the end of the message >>

OK, here is a summary of the steps involved for me to create a local
repository behind a firewall:

- SOCKS5 (needed if you are behind a firewall)
  + Download:
    http://www.socks.nec.com/cgi-bin/download.pl

  + Build and install.

  + Configure to use a socks5 server your site provides:
    * Create /etc/libsocks5.conf:
sockd @=<your_socks_server>,<your_socks_server>.<domain> 0.0.0.0 0.0.0.0

  + Reference:
    http://www.socks.nec.com/socksv5.html

  + How to socksify an application:
    http://www.socks.nec.com/how2socksify.html

- CVS
  + Download:
    http://www.cyclic.com/pub/

  + Build and install.

  + Reference Manual, etc.:
    http://www.loria.fr/~molli/cvs-index.html

- rsync

  + Download:
    http://rsync.samba.org/

  + Socksify rsync source (needed if you are going to use rsync from
    behind a firewall), the quick'n'dirty approach:
    * main.c (main): add 'SOCKSinit (argv[0]);' to the beginning
    of main ().
    + rsync.h: add '#define SOCKS' and '#include <socks.h>' to the
    beginning of file.
    + Makefile.in: add '-L/usr/local/lib' (or the libsocks5 install
    location) and '-lsocks5' to the rsync link line.

  + Configure / Make / Install.

  + Reference:
    rsync(1) man page.
    http://sourceware.cygnus.com/sourceware/ under 'anonymous rsync' link.    

- Local repository creation:
  % mkdir -p <local_repository_root>
  % cd <local_repository_root>
  % rsync --archive --delete --checksum --compress --stats \
    rsync://sourceware.cygnus.com/src-cvs .

- Extract source (this creates <work_directory>/src/ tree with all
  necessary gdb and dejagnu components):
  % setenv CVSROOT <local_repository_root>
  % cd <work_directory>
  % cvs checkout -r HEAD dejagnu gdb

- Routine synchronization of src-cvs repository:
  Use the same rsync command above to synchronize.

That's it!  BTW the <local_repository_root>/CVSROOT/modules file lists
the module aliases / names in the repository, and I found it useful to
decide the module names to use in the cvs checkout command line.
Also, the rsync command line below dumps the list of repositories
available, which I used to figure out that the repository name
for src/cvs is actually src-cvs (that was not apparent to me as a
non-CVS user and was not mentioned in the
sourceware.cygnus.com/sourceware 'anonymous rsync' link):

  % rsync --archive --delete --checksum --compress --stats \
    rsync://sourceware.cygnus.com/ .

- Jimmy Guo, guo@cup.hp.com


>When you get it working, I would appreciate hearing about the procedure
>you used to (finally) make it work.  (You might just want to send a
>followup reply to gdb@sourceware because I suspect that there are others
>out there who'd also like to know.)

Re: Moving Linux-specific stuff out of i386-tdep.c

[Andrew Cagney]

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

Eli Zaretskii wrote:
> 
> > The 8.3 uniqueness rule definitly still applies.
> 
> Should I post a list of files which violate that rule?

Sorry, applies when it matters - any files you need. :-)

	Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000207093417.A10546@lucon.org>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00126.html
Content-length: 1540

On Mon, Feb 07, 2000 at 09:08:51AM -0800, Jim Kingdon wrote:
> > * Support for unloading of shared libraries.  The current code-base
> >   doesn't really support this.  HJ Lu forwarded some patches that hack
> >   around this, but I don't think they are acceptable.  They introduce
> >   two more (uneccessary) hooks.  Personally I don't fixing this for
> >   GDB 5.0 terribly important.  There isn't that many code out there, that
> >   explicitly unloads shared libs.
> 
> As far as I know there is more out there than you might realize.  A
> modern application like mozilla uses dlopen() a lot (feel free to
> flame about whether this tendency is a fad or really useful but that
> isn't the point).  For example see
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130
> 
> 
> > I think having an "x86 linux native" port with working threads support
> > in GDB 5.0 is very important.
> 
> Have you tried GDB from CVS in the last 6 months or so?  I'm not aware
> of any known bugs and Red Hat Linux has been shipping with the code
> which is in CVS for a while (I can offer details if needed).
> 

gdb 4.17.0.14 has one patch from Sam to deal with shared libraries.
People who want to debug shared libraries may not want to use gdb
in CVS. As you have mentioned above, it is not that unusual nowdays.
We have patches and they seem to work. We can make gdb 5.0 to work
with shared libraries. If we continue ignoring the working patches
without providing an alternative, we are sending the wrong signals
to those contributors.


H.J.
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C6D95A.FCEAE1C1@apple.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00623.html
Content-length: 2217

Mark Kettenis wrote:
> 
> Hi,
> 
> Over time quite a lot of Linux-dependent stuff has been added to
> i386-tdep.c, and I think it's time to move that into its own file.

Bear in mind that it should be possible to build a foo-x-linux
cross debugger, if for no other reason than to bootstrap new
systems.  *-nat.c files are by definition native-only, and won't
get linked into a cross debugger.

I generally like to look at foo-tdep.c as a quasi-library of
knowledge about foo.  It makes it easier to share code that
is the same or nearly the same for different OSes running on
the architecture.

> But before I do that I'd like to get some clarification on some
> issue's.
> 
> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.

Well, the systems in question are quite old, we've had long filenames
in GDB sources for quite a while, and only the DJGPP folks have
whined about it. :-)  Personally, I think we should try to stay
within the 14-char limit, because a) everything gets unwieldy when
people start trying to put the documentation into the filenames
like i386-linux-nat-for-red-hat-6.1-beta2-except-in-nepal.c
and b) because doschk is a handy way to check on all the filename
issues at once.

If somebody has an actual System V machine that chokes when
handed a tar file with long filenames, now would be a good time
to speak up...

> 2. Should I postpone creating the new -tdep.c file until after the
>    release or not.  Andrew has been telling us to avoid gratuitous
>    changes to make it easier to apply outstanding patches.  But on the
>    other hand, after 5.0 is released, I hope to see a lot new patches
>    generated against 5.0.  So creating the new file before 5.0 would
>    make applying those new patches a lot easier.

If the Linux patch backlog were to be emptied out, you wouldn't have
this problem. :-)  But seriously, if you change it now, before all
submitted patches have been dealt with, then it would only be fair
for you to adapt those patches yourself.  So it seems more like a
question of whether you want to do more work now vs later.

Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Stan Shebs <shebs@apple.com>, Mark Kettenis <kettenis@wins.uva.nl>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E178BC.67987E6@cygnus.com>
References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00832.html
Content-length: 1723

"H . J . Lu" wrote:
> 
> On Thu, Mar 09, 2000 at 04:53:39PM -0800, Stan Shebs wrote:
> > "H . J . Lu" wrote:
> >
> > > > A GNU/Linux distributor is free to build a GDB that regexp from an
> > > > installed glibc. Actually such a distributor is free to do what ever
> > > > they like :-)
> > >
> > > Are you saying as far as gdb is concerned, you have no interests
> > > whatsoever in glibc nor helping glibc developers and GNU/Linux
> > > distributors? If it is true, that is too bad.
> >
> > Let's not get all tense here!  There's a balance to be struck between
> > being self-contained and depending on system stuff, and there's no
> > single rule that applies in all cases.  For instance, GDB includes
> > libiberty, even though many of the functions are available on most
> > systems by default, including Linux, but I don't seem to hear anybody
> > complaining about that bit of redundancy.  (Hmmm, why isn't regex
> > in libiberty anyway??)
> >
> > In the case of GDB on Linux, part of our problem is that we have
> > to support GDB on all versions of Linux, not just the latest
> > kernel and library.  So if there is *any* version of glibc with
> > a problematic regex, say one from 4-5 years ago, we need to think
> > hard about whether we're going to hose people running a Linux that
> 
> We can put some check to see if regex in glibc is in ok. From
> the glibc log in CVS, my simple check seems ok. I can even restrict
> it to glibc 2.1 and above. I don't think it should be any problem.

FYI,

I've put this all on hold until after 5.0.
Pokeing around glibc regex is ``on the move''.  It continues to be
developed and fixed.  One thing that has me wondering is i18n and what
effect that had on regex.

	Andrew
From dj@delorie.com Sat Apr 01 00:00:00 2000
From: DJ Delorie <dj@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C6E28D.46F16538@delorie.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local> <kettenis@wins.uva.nl> <1000308222742.ZM8876@ocotillo.lan> <20000308173031.A11900@cygnus.com> <1000308225132.ZM8953@ocotillo.lan>
X-SW-Source: 2000-q1/msg00629.html
Content-length: 930

Kevin Buettner wrote:
> Here's what Stan had to say about the matter:
> 
>     Names need to be 8.3 unique so djgpp works.  The critical files...
>     The 14-char thing is an old System V limitation, and is...

The key thing to note is that 8.3 filesystems truncate the *base*
name, not the whole file name.  So, verylongfile.c becomes verylong.c
and the object file is verylong.o.  With SYSV filesystems,
verylongfilename.c becomes verylongfilena and the object file
is *also* verylongfilena, and it overwrites the source.

So, "8.3" means 8.3 *unique*, but longer is OK (like the old FORTRAN
rules that variables could be long, but had to be unique in the
first six letters) as long as it gets safely truncated.

Also note that ftp.gnu.org has a package called "doschk" that
checks for 8.3-unique and sysv-14 problems.  It's trivial
to build and use (ls -1R | doschk) and may prevent problems
down the road.
From phdm@macqel.be Sat Apr 01 00:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb@sourceware.cygnus.com
Subject: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00794.html
Content-length: 904

Up to some years ago, gdb could be compiled by a K&R C compiler.
Now, it can not anymore, and the change seems to be deliberate.

It seems to me that the freedom of the gdb users is now restricted compared
to the previous versions because of the need of an ISO-C compiler instead
of any C compiler to compile it.

And I do not understand why the same reasons that apply to binutils and gcc
do not hold for gdb.  gdb, because it is better than the debugger you get
with your operating system, is needed to bootstrap the installation of
gas, gld, or gcc in the likely case that not everything works well
the first time.

Just my opinion

Philippe

P.S. : I am willing to check that gdb can be compiled by a K&R compiler
and submit the needed patches, if that can help.

Philippe De Muyter  phdm@macqel.be  Tel +32 2 702 90 44
Macq Electronique SA  rue de l'Aeronef 2  B-1140 Bruxelles  Fax +32 2 702 90 77
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@cygnus.com>
Cc: gdb@sourceware.cygnus.com, johan.rydberg@netinsight.se
Subject: Re: problem with register display
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7A12A.707179E3@cygnus.com>
References: <38C6691D.C3F05223@netinsight.se> <o566uxjty7.fsf@toenail.to.cygnus.com>
X-SW-Source: 2000-q1/msg00641.html
Content-length: 524

"Frank Ch. Eigler" wrote:

> > And, how do I from gdb call the `sim_info´ function?  [...]
> 
> I see no gdb command that hooks to this function.  But, one is not
> hard to add.  Look up the sim option processing functions.  They work
> from both within gdb (using the "sim" command prefix) and the sim
> command line (as long --options).

Try ``info target'' (or ``info files'').

Looking in gdb/remote-sim.c it would appear that sim_info() is called
conditional on there being an executable.  I can't think why.

	Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Jim Kingdon <kingdon@redhat.com>, Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A464AF.535C7505@apple.com>
References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <bg0v08f69.fsf@rtl.cygnus.com> <200002111929.OAA13997@mescaline.gnu.org>
X-SW-Source: 2000-q1/msg00226.html
Content-length: 886

Eli Zaretskii wrote:
> 
> Andrew Cagney writes:
> 
> > > So having said all that, do you still want submit.html or equivalent
> > > in the distribution?  Having it both places seems like kind of a
> > > maintenance pain and seems to me that having the distribution point
> > > to the web site probably works.
> >
> > Yes,  I think the GDB distribution should contain the document.
> 
> Perhaps it is better to make this document part of the GDB manual.
> Then we could be sure it won't be forgotten due to changing fortunes
> of time...

The GDB manual is for users only, so not really appropriate there.  The
internals manual does have a section on contributing, but it could use
some tinkering.

We should consider installing more links from the web pages to htmlized
copies of manuals - that should help improve awareness that the manuals
already contain a lot of useful info.

Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF7E1D.4E0A904D@cygnus.com>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00516.html
Content-length: 354

Tom Tromey wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> Andrew> GNU/Linux/i386:
> 
> Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> with older kernels (I still run 2.0.34).

Tom,

I belive JimB's bubbled this up to the top of his queue and made it one
of the things try to get into 5.0

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb cvs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF0551.9B4FE1E@cygnus.com>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu>
X-SW-Source: 2000-q1/msg00514.html
Content-length: 299

"Gabor Z. Papp" wrote:
> 
> | cvs server: Updating gdb
> | U gdb/CONTRIBUTE
> 
> [...]
> 

> 
> Is this correct?

Were you doing a: ``co gdb'' over the top of an existing tree?  I've
encountered that message then.
I suspect it isn't correct but, from what I saw it still did what I
wanted.

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: --target=powerpc-elf broken in current sources?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A8ACD1.E343CD0C@cygnus.com>
References: <200002150108.RAA03716@haight.constant.com>
X-SW-Source: 2000-q1/msg00280.html
Content-length: 406

Benjamin Kosnik wrote:
> 
> > try on older linux release yadda yadda yadda
> 
> No. I haven't. Is gdb only working on older linux releases?

To put it another way, is there any thing to suggest that this is a
generic build problem or something specific to your Linux host?

The powerpc simulator contains some pretty scary linux emulation code. 
I can imagine that suffering from decay over time.

	Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: blizzard@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002181853.e1IIr1t02301@delius.kettenis.local>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> <20000218101700.A19913@lucon.org>
X-SW-Source: 2000-q1/msg00340.html
Content-length: 1098

   Date: Fri, 18 Feb 2000 10:17:00 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Fri, Feb 18, 2000 at 12:42:01PM -0500, Chris Blizzard wrote:
   > Christopher Blizzard wrote:
   > > 
   > > Program received signal SIGTRAP, Trace/breakpoint trap.
   > > 0x404cbd41 in ?? () from /lib/libc.so.6
   > > (gdb) shar libc.so.6
   > > Reading symbols from /lib/libc.so.6...done.
   > > 

   There are many linuxthreads problems since lin-thread.c was
   introduced. Unfortunately, I don't have the time to track it
   down.

This isn't one of them (at least the problem that was origionally
reported by Jim Kingdon).  The bug report is from before lin-thread.c
was introduced.  As a matter of fact, I have seen a spurious SIGTRAP
on Solaris 2.6 too in the gdb.threads/pthreads test.  And I also see
them quite frequently on the Hurd too (where every program is
multithreaded).  Looks like there is something wrong in the platform
independent threads code.

As for the "many linuxthreads problems": would you please tell us what
they are.  Apart from the spurious SIGTRAPs I'm not aware of any.

Mark
From jsm@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jsm@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: GDB Developers <gdb@sourceware.cygnus.com>
Subject: Re: GDB ftp site in hyperspace ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000131225201.A11482@cygnus.com>
References: <200002010648.WAA28893@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00082.html
Content-length: 707

On Mon, Jan 31, 2000 at 10:48:42PM -0800, Todd Whitesel wrote:
> I just tried to ftp a fresh tarball of 4.18, but the ftp.cygnus.com site
> claims the directory has moved to sourceware, yet the /pub/gdb directory
> on sourceware appeared empty...
> 
> I used the shell ftp client on solaris... What gives?

The shell ftp client on Solaris is broken.  Use another client, such as
ncftp or netscape, to browse the ftp site.  Or use another OS, say... oh
I don't know...  maybe Linux?  :-)

(I'm not joking about the Solaris ftp client being broken; I think it
will still work if there is at least one file in a given directory.  The
directory you're looking at has no files in it, only subdirectories)

Jason
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gatliff@haulpak.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001271910.OAA04242@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00062.html
Content-length: 849

> I just moved my gdbstubs library to sourceforge.net.

Cool!  I've added a link from http://sourceware.cygnus.com/gdb/ - at
the bottom of the page with the other links.

> The release license is LGPL.

Are you sure you want this rather than public domain (as the stubs in
the GDB distribution) or XFree86-style?  I suppose maybe it is a moot
point if people leave out the stubs when they actually ship code, but
in general, the LGPL's requirement that people make available .o's
makes it somewhat impractical for many embedded applications.

> I'll also take any suggestions on how to manage the project--- I'm not
> exactly skilled in the art of extreme multitarget development, at
> least not yet.  :^)

You've already done the hard part by being dumb ^H^H^H^H brave enough
to start the project!  Feel free to ask if you have specific
questions.
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003040704.CAA08168@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <200003031240.e23CeRn00162@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00536.html
Content-length: 170

> The suggested syntax could probably be
> improved, since "xx" isn't very descriptive.  People with bright ideas?

How about "x/seg=SEG OFFSET"?  Or simply "x SEG:OFF"?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Anthony Green - Java Maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C71B06.94E21103@cygnus.com>
X-SW-Source: 2000-q1/msg00631.html
Content-length: 2168

Hello,

I've made Anthony Green the Java maintainer.

	enjoy,
		Andrew
Thu Mar  9 14:21:07 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* MAINTAINERS (Core): Anthony Green is the Java - including
 	testsuite - maintainer.  Reformat testsuite and language support
 	sections

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.21
diff -p -r1.21 MAINTAINERS
*** MAINTAINERS	2000/03/05 08:46:56	1.21
--- MAINTAINERS	2000/03/09 03:26:56
*************** maintainers when resolving more generic 
*** 56,62 ****
  The host maintainer ensures that gdb (including mmalloc) can be built
  as a cross debugger on their platform.
  
- hp testsuite (gdb.hp)	*Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
  djgpp native		*Eli Zaretskii		eliz@gnu.org
  			DJ Delorie		dj@cygnus.com
  MS Windows (N.T., CE, '00) host & native
--- 56,61 ----
*************** tracing			Michael Snyder		msnyder@cygnus
*** 90,96 ****
  threads			Michael Snyder		msnyder@cygnus.com
  breakpoint.c		Michael Snyder		msnyder@cygnus.com
  language support	David Taylor		taylor@cygnus.com
! C++ language support	Daniel Berlin		dan@cgsoftware.com
  expression eval		David Taylor		taylor@cygnus.com
  defs.h			David Taylor		taylor@cygnus.com
  utils.c			David Taylor		taylor@cygnus.com
--- 89,96 ----
  threads			Michael Snyder		msnyder@cygnus.com
  breakpoint.c		Michael Snyder		msnyder@cygnus.com
  language support	David Taylor		taylor@cygnus.com
!   C++ support		Daniel Berlin		dan@cgsoftware.com
!   Java support		Anthony Green 		green@cygnus.com
  expression eval		David Taylor		taylor@cygnus.com
  defs.h			David Taylor		taylor@cygnus.com
  utils.c			David Taylor		taylor@cygnus.com
*************** rdi/adp protocol	Fernando Nasser		fnasse
*** 108,113 ****
--- 108,115 ----
  gdbserver		Stan Shebs		shebs@apple.com
  documentation	 	Stan Shebs		shebs@apple.com
  testsuite	 	Stan Shebs		shebs@apple.com
+   hp tests (gdb.hp)	*Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
+   Java tests (gdb.java)	Anthony Green 		green@cygnus.com
  Kernel Object Display	Fernando Nasser		fnasser@cygnus.com
  
  
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: muller@cerbere.u-strasbg.fr, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003040706.CAA08171@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <38BFB50A.606036CF@cygnus.com>
X-SW-Source: 2000-q1/msg00537.html
Content-length: 232

> The theory is that if ``CORE_ADDR'' is made in to a pretend object
> (ISO-C remember :-) and then the rest falls out....  As they say, the
> proof is left as an exercise to the reader.

Sorry, I don't follow.  Can you elaborate?