From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,624d2df910935ed3 X-Google-Attributes: gid103376,public From: jm59@prism.gatech.edu (John M. Mills) Subject: Re: comp.arch.embedded Date: 1997/12/18 Message-ID: <67bdtt$mqp@acmez.gatech.edu>#1/1 X-Deja-AN: 299350436 References: <34991C2D.127F@sh.bel.alcatel.be> Organization: Georgia Institute of Technology Newsgroups: comp.lang.ada Date: 1997-12-18T00:00:00+00:00 List-Id: Jos De Laender writes: >Can someone give me some explanation (or the pointer to explanation) >on the following : >How does one debug code which is running on a target board processor >using a debugger running on a PC or workstation (so running on >a different processor). >How is synchronized on breakpoints, how is single stepped ... >Does the debugger have knowledge about the target processor >instructions ? >Are there standardizations needed and/or common ? Can each debugger >be used for each processor ? If not, by what it is determined ? I can't answer the 'how', but I can describe a working example. We debugged embedded Ada83 code cross-compiled from VAX/VMS to MVME147 (68030?) boards. Motorola provided a monitor-style debugger which could connect by either serial and ethernet to a remote, which was our VAX. The code was written (linked and located) into RAM space on the board for speed reasons, but this then paid off in debugging, since th monitor-style debugger could place traps, change parameter data, etc. No processor 'ICE' was needed (although we did use an HP 'ICE' system while debugging our in-house VME boards). The VAX end was DEC's resident debugger, which was able to give us source-level traces, use the compiled code's symbol table, as if we were debugging native code. The compiler was EDS-Scicon's XD-Ada (83): slow and clunky, but we were happy with the resulting code. Linking was by DEC's built-in linker, which has some target-independence like the debugger. We used the serial port to download a bootstrap for the ethernet support, then used the enternet to download our code and for debugging communications. We patched the bootstrap PROM to copy an image of our code into the intended RAM space in the deployed version. Since this image matched the debug version in both location and execution medium, we had little risk in moving from cross-loaded debug to PROM-booted deployed versions. The serial step had to be repeated at each power-up, but we could reset the boards, reload our code, and start new debug sessions without dropping the Ethernet connections. We had three processors in our system. At integration, we debugged them simultaneously, using a separate console login for each processor (and of course a separate Ethernet address, through a single physical connection -- each processor had a dedicated serial link for the lowest-level bootstraping, but if you could start directly to Ethernet this is not needed). An X-Window or virtual-terminal environment would allow this to be done from a single physical console, but we had different individuals debugging each processor's executable. This required a fair amount of trust and knowledge as to how the various executables were going to interact, but we were OK for that -- no physical violence occurred! Perhaps this outline of the process will stimulate further thoughts and suggestions. I expect other manufacturers of embedded development packages have comparable or better approaches. (These materials were selected about 8-9 years ago and could now be considered obsolete, but they in fact worked.) Regards -- john mills -- John M. Mills, Senior Research Engineer -- john.m.mills@gtri.gatech.edu Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834 Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX) "Lies, Damned Lies, Statistics, and Simulations."