Hi there,
First of all, I thank you, Allen and all other alice members, for
bringing us this real UNI* system.

Some questions about gdb.  Running gdb on NetBSD/mac68k[1.0], I came
up with some unexpected behaviour of the debugger:
  - "print" command seldom reported correct values.
  - debugger suddenly attempted to clear/insert breakpoint(s) even though
    the command I entered is "continue", not any of "break", "clear",
    "watch", etc.
  - debugger catched an unexpected signal and sometimes the system went
    down to the low-level debugger.

For it is hard to believe that the debugger has this sort of bugs, I
guess the problem lies not in gdb but anywhere else (kernel, gcc, or
my system's configuration?).  But, anyways, I'm clueless now.  Was
there anyone who reported similar problem?  Is this because of the
kernel I'm using (which might be rather old)?  Has gdb been ever
patched after the official release of NetBSD 1.0 package? ? ? ...

Here are some more details.
[Configuration]
  CPU: Macintosh SE/30
       no external cards (video, accelerator, etc)
  Memory: 8MB
  Disk: about 160MB for / partition
        some 16MB for swap
        that's all, in terms of UFS
  NetBSD version: 1.0
        Kernel, libraries, binaries, and anything else came from the
        NetBSD official release 1.0 of October 1994.
  gdb version: the one that came with NetBSD 1.0

[What I did]
  Wrote a simple test-program called "loop.c" and compiled it with
  gcc with -g option.

  > April% cat loop.c                                                      
        
  > #include <stdio.h>
  > #define MAX     36
  > 
  > void main(void)
  > {
  >     int i;
  > 
  >     for (i=(int)4; i<MAX; i++)
  >       (void)printf("Loop count = %d.\n", i);
  > 
  >     (void)exit(0);
  > }
  > April% gcc -g -o loop

  Ran the program "loop" under gdb, stoped it in the for loop, and
  examined the value of variable "i".  Repeated this twice or more.

  > April% gdb ./loop                                                      
        
  > (gdb) break 9
  > Breakpoint 1 at 0x2700: file loop.c, line 9.
  > (gdb) run
  > Starting program: /home/mizuno/TestStuff/progs/./loop 
  > 
  > Breakpoint 1, main () at loop.c:9
  > 9             (void)printf("Loop count = %d.\n", i);
  > (gdb) print i
  > $1 = 4
  > (gdb) print i
  > $2 = 0            <== gdb reports bad value
  > (gdb) 

  After this point, repeating "print i" and "cont" commands sometimes
  caused another curious thing like this:

  > (gdb) cont
  > Continuing.
  > Cannot insert breakpoint 1:
  > The same program may be running in another process.
  > Error accessing memory address 0x2700: No such process.
  > (gdb) 

[Some more comments: what I tested]
  1) gdb recompiled
     Using the source codes of gdb that were contained in NetBSD 1.0
   distribution, I re-compiled gdb and tried again.  The same results.

  2) added debugging printf()'s and recompiled
     In the function "print_command_1()" [file: gdb/printcmd.c], I
   put some 8 printf() statements for debug purpose.  The printf()'s
   were to see what the returned values were after "evaluate_
   expression (expr)" call was returned.  (see "patch" below)
     Though it may sound strange, with this patch, gdb reported
   correct values.  In the case of "loop", no matter how many times
   "print i" command was repeated, correct value for "i" was
   displayed.
     But, gdb still showed other unexpected behavior such as "Cannot
   insert breakpoint".

  3) printcmd.o unoptimized
     I suspected gcc might be wrong (i.e. optimizer's bug) and
   recompiled printcmd.c (w/o debugging printf()'s) without "-O"
   option.  (Then re-link it into gdb).  Results were same as the
   original one.  "print" command seldom reported right values.

That's it.

Any suggestion will be welcome.  I've checked KNOWN-BUGS, FAQ's and
other sources that I can use to see if this problem was already
reported and fixed.  But none was found.  So, your help will be very
much appreciated.  Thanks in advance.
                                           -- Haru Mizuno
                                              mizuno@twics.com
                                              mizu@cs3.cs.oki.co.jp

P.S.
     Should this be a bug and you prefer a "send-pr formatted" bug
report, please let me know.  I'll try.

Appendix:
*** /home/mizuno/utils/GDB/gdb/printcmd.c.org   Fri Jan 28 21:40:25 1994
--- /home/mizuno/utils/GDB/gdb/printcmd.c.dbg   Sat May  6 11:46:03 1995
***************
*** 746,751 ****
--- 746,779 ----
        cleanup = 1;
        val = evaluate_expression (expr);
  
+   printf("DEBUG: value={\n");
+   printf("DEBUG   lval= %d,\n", (int)val->lval);
+   printf("DEBUG:  location { address = 0x%x\n", val->location.address);
+   printf("DEBUG:             internalvar = 0x%x\n", val->location.internalvar)
;
+   printf("DEBUG:             regnum = %d\n", val->location.regnum);
+   printf("DEBUG:           }\n");
+ /*
+     int offset;       
+     int bitsize;
+     int bitpos;
+  */
+   printf("DEBUG:  frame_addr = 0x%x,\n", (int)val->frame_addr);
+ /*
+     struct type *type;
+     struct value *next;
+     short repeated;
+     short repetitions;
+     short regno;
+  */
+   printf("DEBUG: lazy = %d\n", (int)val->lazy);
+ /*
+     char optimized_out;
+     union {
+       long contents[1];
+       double force_double_align;
+     } aligner;
+  */
+ 
        /* C++: figure out what type we actually want to print it as.  */
        type = VALUE_TYPE (val);