tru@sactoh0.sac.ca.us (Troy R. Underwood) (01/19/91)
We are looking for a debugger, similar to the dbx and/or dbxtool used on Suns. We need it to work with both the Sun3 executables and Sun4 executables. What we want to do differently in that we need to be able to run the debugger in one window/terminal and the program and it's screen input and output to run in another terminal/window. I understand that Saber C has this capability, but at a very high cost. Next question: Does any one have a script to lock the laser printer when someone needs to use letterhead. We are not fortunate enough to have multiple trays and/or multiple laserprinters. Thanks in advance. Troy
poffen@sj.ate.slb.com (Russ Poffenberger) (01/23/91)
In article <1375@brchh104.bnr.ca> tru@sactoh0.sac.ca.us (Troy R. Underwood) writes: >We are looking for a debugger, similar to the dbx and/or dbxtool used on >Suns. We need it to work with both the Sun3 executables and Sun4 >executables. What we want to do differently in that we need to be able to >run the debugger in one window/terminal and the program and it's screen >input and output to run in another terminal/window. One way to achieve this, although less convenient, is to start the program to be debugged in one window. You need to make sure that it has a way to pause execution. More later. Get its process id using ps. Start dbx or dbxtool. When it comes up, enter "debug progname pid". Make sure you are cd'ed to the directory where the program resides. What this will do is load the symbols, and attach to the already running program. The IO for the program stays in the original window. You may have to use the "use" command and do "up" then "down" to see the source. You can force the test program to pause, by putting "pause()" near the beginning of the file. As soon as dbx attaches, it signals pause and it will continue normally. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
gnu@toad.com (03/19/91)
The GNU Debugger, gdb, can run the debugger in one window and the program in another. I have run it in this mode, by finding out the pty name of a shell window with the "tty" shell command and then doing something like "sleep 999999" in that window. Then, in another window, I run gdb on the program, specify that tty name to the gdb "tty" command, and type "run". GDB can also do the "attach" trick described by an earlier poster, where you start the program in one window and "attach" a GDB from another window to it by saying "attach PID". gdb-3.5 is the latest released version, available in all the standard spots, like uunet and prep.ai.mit.edu. To compile this on a Sun you have to change the Makefile by removing the definition of TARGET_ARCH. It was there because Sun Make used it to control cross-compilation, forcing the current architecture to be passed to the compiler by default. This broke when using gcc, because gcc did not know how to parse a switch like -sun3. So TARGET_ARCH= (nothing) was added to the makefile to null out this feature. Well, in the next release Sun's infinite wisdom changed this "feature", so now setting TARGET_ARCH to nothing produces a "-target " switch to the compiler, followed by nothing, which not only breaks GCC but also breaks under the sun unsupported C compiler. Just remove the line that says: TARGET_ARCH= from Makefile.dist and rerun config.gdb to rebuild Makefile, then make it.