🚀 go-pugleaf

From article <16:joerg.winckler@sun1.ruf.uni-freiburg.dbp.de>, by joerg.winckler@sun1.ruf.uni-freiburg.dbp.de:
> It's not a bug but a cry for help. Does anyone know
> anything about running gdb on Apollo workstations with
> SR 10 ?  I need the machine dependent files
> param.h
> pinsn.c
> opcode.h
> dep.c,
> and I do not know much about the workstations
> to configure these files for myself.
> Can anyone help me ?!?
> 
> Thanks, Joerg Winckler
> 
> + Joerg Winckler, University of Freiburg, Fed. Rep. of Germany +
> + email: winckler@sun1.ruf.uni-freiburg.dbp.de                 +

I don't know of anyone with a complete port.  The status of what
I've been doing is...

   I haven't even started looking at reading Apollo symbolic debugging
   info; it's totally different from both a.out (dbx, etc.) and coff
   format (and it's apparently only "public" as of sr10.2).  While
   apollo sr10 binaries do have a COFF-format symbol table it seems
   to only contain the minimum amount of information necessary to link
   the program.  "Extra" symbolic debugging information seems to be
   completely contained in their special sub-sections of the file.

   With no sub-process started, the basic command processing loop works;
   I can examine memory, disassemble, etc.

   I can get a sub-process started, single-step it, etc.  However examing
   memory doesn't work (it returns garbage results), breakpoints don't
   work, etc.  Plus when I tried to change memory in the data segment
   my node immediately crashed to the phase 2 boot shell, with the
   location it stopped at matching the data segment address I tried to
   change.

   ...to summarize, I'm very doubtful that the ptrace memory examine/modify
   commands work under sr10.1 (at least in the way I've tried to use them).

dgc