In a message dated 9/28/2006 6:04:01 A.M. Eastern Standard Time,  
is@netbsd.org writes:
>>>Uhm, yes. GDB must have a way to tell the  OS to run the program in a
>>>trapping way - apparently the NetBSD  gdb doesn't know how to do that for 
>>>a SunOS program. (Always  assuming single step does work for your 
program...
>>>but stepi  works on a 3.0 system with a 4.0_BETA  kernel.)
>>>
>>>You did use "stepi", right? 
 
Yes, stepi (machine instruction step) just kept right on going.  I  found a 
SunOS Verdix ada source-code debugger that has the ability to  machine step 
through programs.  I was able to get it to  debug (via some shennanigans) 
non-verdix ada compiled code, and ran it on  the real sun3 and inside TME.  I just 
had it step through thousands of  lines of m68k instructions, output all the 
registers and stack at each m68k  instruction.  I then updated the output to 
adjust the starting stack  address to the same value for tme/real sun3 and 
performed some adjustments to  allow for an easy "diff".
 
Found a major TME problem:
    movel sp,-(sp)
doesn't work.  The value pushed to the stack is the  predecremented sp value 
instead of the original sp.  After fixing this,  most of the remaining 
gcc-3.3.3 testsuite problems inside TME went away.   Woot!  I'm investigating other 
possible problems along these lines.
 
It still would be nice to be able, with GCC, to assemble the output of  
objdump dissassembled executables.  That seems like such an awesome  feature; I 
don't know why objdump output is not immediately in assemblable  form.
/arthur