From dan Tue Jan 10 13:20:25 1995 From: Denis Nicole Message-Id: <3563.9501101320@orca.ecs.soton.ac.uk> Subject: T9000 tools update To: tcarden@parsys.co.uk, bobdob@cernvm.cern.ch, gassilloud@telmat.fr, paul@ace.nl, rob@pact.nl, emmanuel@parsys.co.uk, pmiguel@fi.upm.es Date: Tue, 10 Jan 1995 13:20:21 +0000 (GMT) Cc: dan (Denis Nicole), rs1 (Rajini Sivaram) X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 6545 Status: OR Rob Kurver is now using the T9000 SCOTT tools at ACE for compiler development. Based on his feedback, and in particular to help him use gdb more effectively for compiler and library debugging, we have created new releases of the components of SCOTT. These can be obtained by FTP from ecs.soton.ac.uk in directory /pub/transputer/t9000. 1. iserverc.tar.gz replaces iserverc.tar.gz The only change here is to add the ACE/PACT -C option to the server. This allows the server to skip over a number of transputers, in a similar way to the INMOS iskip utility. 2. wish1.tar.gz and gdb1.tar.gz replace wish.tar.gz and gdb.tar.gz This provides several gdb enhancements, as requested by Rob: > > 1. 'info all-registers' display the wrong values, and not the FPU registers > ('info registers' correctly displays the non-FPU registers) This bug has been fixed. GDB now displays the FPU registers in floating point and hex format. FP status register is also displayed. > > 2. it's not possible to exit from gdb after the application itself has > been terminated It should be possible to exit from gdb if the application terminates successfully, or if the iserver is terminated. > > 3. when I do a Sun4 'trace' of the iserver when it's running in debug > mode, I see an endless stream of getpid() calls; if this is being > done on request of the transputer program it causes an enormous > overhead on the host-transputer interface I tried tracing the iserver with gdbtest.out in the directory examples, it called 'getpid' only once. The server calls made by the debug stub on the transputer are only socket read and write. > > 4. when a 'j 0' is encountered which does not correspond to a breakpoint > set through gdb, it is impossible to ignore this; it would be nice if > it were possible to ignore all such 'j 0' instructions, or, at the > very least, if one could continue after this trap The 'j 0' instruction is not ignored by gdb, but you can continue after this trap. > > 5. after any exception not caused by a breakpoint set by gdb, the program > stops there; gdb correctly points at the instruction causing this trap, > but it is not possible to ignore the trap ('continue' goes back to the > instruction that caused the trap, which immediately causes the same > trap to occur again, and 'continue *' for > some reason causes the debugger to crash or the program to hang or > stop) This has been modified. You can continue after an exception, the next instruction is executed, so the traps will not occur again. The Status register has also been made accessible to gdb. So to ignore traps, the Trap enable bits in the status register can be modified. > 6. I browsed through t9000-stub.c and saw some constants hardcoded in, > e.g. only memory addresses between 0x80000000 and 0x80400000 are > considered legal; this should be improved This has been modified. The total memory is now passed by the configuration script to the loader, and is set in the 'processor' data structure by the startup routine . The debugger reads the memory specifications from this structure. > > Related to 5, I am now wondering what happens with exceptions when the > program is not running under debugging control. In this case, there's > no exception handler, so the exceptions are ignored and the program simply > keeps on running. But are instructions that cause exceptions executed? > If not, this may well explain some of the problems we're now trying to > find and fix. I'll check the T9 docs tomorrow, but perhaps you can > already shed some light on trap handling in SCOTT. Trap handler is setup only in debugging mode in SCOTT. In non-debugging mode, the task runs with a NULL trap handler. To generate a faster version of the configuration script, set the TCL variable 'GenerateFastConfig' to '1' in the file config1.tcl. Run this script using the command 'iserver -sb tclsh.run config1.tcl'. A file 'fastconfig1.tcl' is generated. This file can be used to configure the T9s by changing the variable 'CONFIG_FILE' to fastconfig1.tcl in the scripts 'coffboot' and 'wishboot'. The faster version of the configuration script does not check for any errors during configuration. 3. Telmat is having difficulty booting their T9000s with SCOTT Trevor, we are using your T9000 box as delivered by Parsys. Can you help with any configuration differences between Parsys and Telmat kit? From yma%TE-10%TI-1@telmat.fr Thu Jan 5 10:36:57 1995 Received: from relay1.fnet.fr by bright.ecs.soton.ac.uk; Thu, 5 Jan 95 10:31:35 GMT Received: from telmat.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA29676; Thu, 5 Jan 1995 11:31:37 +0100 (MET) Message-Id: <199501051031.AA29676@relay1.fnet.fr> Subject: SCOTT To: D.A.Nicole%ecs.soton.ac.uk%relay1%telmat@TI-1 Date: Thu, 5 Jan 95 11:16:03 HIV From: Yves MARCHAL Reply-To: yma%TE-10%TI-1@telmat.fr X-Mailer: ELM [version 2.3 PL11] Received: from TI-1 by telmat; Thu, 5 Jan 1995 11:21 HIV Received: from TE-10 by TI-1.telmat.fr; Thu, 5 Jan 1995 10:08 GMT Content-Type: text Content-Length: 794 Status: OR Dear Denis I want to use SCOTT. The Iserver tests (xcc.run and icc.btl) and the TCL/Wish tests works correctly. About the T9000 tests I have some problems. The configuring of the C100 and the T9000 seems working good. But the loading of the application don't work. The loading of the data section seems good, but the loading of the text section failed in the second calls to WriteLink (file : wish/vcp/coffload.c - function : LoadSections). This problem appears for all the examples. Perhaps it is due to a bad configuration of the T9000, so could you send me a description of your hardware, mainly of your memory configuration (size of memory, access by 32/64 bits, size of the cache, etc ...), the version of T9000 (have you tested SCOTT on different version of T9000). regards Yves. 4. New progress We now have PVM (but not yet XPVM) running on the t9000s. We have also found a tcl/tk graphical front end for gdb which we are testing with our system. We should be able to demonstrate both to Bob on Thursday. Denis & Rajini