joerg.winckler@sun1.ruf.uni-freiburg.dbp.de (08/30/89)
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 +
dclemans@mentor.com (Dave Clemans @ APD x1292) (08/31/89)
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