wutka@gitpyr.gatech.EDU (Mark Wutka) (01/06/87)
Anybody know of a good debugger that is inexpensive (VERY inexpensive) ?
I have been toying around with the Macro Assembler and I can't even open
the Intuition Library. It bombs when I jump to OpenLibrary and I can't
figure out why. I can't even tell if it is the jump that does it or if
it bombs within OpenLibrary since I can't tell where my program is
loaded into memory so I can't track it very well. Anybody know of a debugger
that would help ?
--
...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!wutka
This is what happens when I roll my head on the keyboard:
kl,miojunhygbtmki,l o.;/,kmoij unhybgtvfrcdjnmki l,o.;p/ijncmcmanis@sun.uucp (Chuck McManis) (01/06/87)
In article <2846@gitpyr.gatech.EDU>, Mark Wutka writes: > Anybody know of a good debugger that is inexpensive (VERY inexpensive) ? > > I have been toying around with the Macro Assembler and I can't even open > the Intuition Library. It bombs when I jump to OpenLibrary and I can't > figure out why. I can't even tell if it is the jump that does it or if > it bombs within OpenLibrary since I can't tell where my program is > loaded into memory so I can't track it very well. Anybody know of a debugger > that would help ? > -- > ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!wutka I don't know of a good debugger but I may know your problem. I have found the only way to reliably start assembly programs is to use the startup code in the back of the Rom Kernel Manual, specifically you must first initialize a variable called "SysBase" to the contents of location AbsExecBase ($4), then you must open the dos library with MOVE.L #dosname,A1 MOVE.l #0,D0 CallSys OpenLibrary And then you can do whatever else you want. But without these two, and in that order you can't do anything. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kim@amdahl.UUCP (Kim DeVaughn) (01/08/87)
In article <2846@gitpyr.gatech.EDU>, wutka@gitpyr.gatech.EDU (Mark Wutka) writes: > Anybody know of a good debugger that is inexpensive (VERY inexpensive) ? > > I have been toying around with the Macro Assembler and I can't even open > the Intuition Library. It bombs when I jump to OpenLibrary and I can't > figure out why. [ I'm posting this for Steve ... /kim ] First of all, are you sure that the library number you're passing is 32 bits (in other words, are the high order bits of D0 0?) Also, is it one of (0, 31, 32, 33)? As for the debugger, if you're using Manx, look at DB. By the 3.4 release this will be a very nice package. Also, Fred Fish wrote a dbug package that can be found on Disk #2, but I think this only for C. [an updated version is on #41] If you have a terminal or another computer to hook up to the serial port, you can imbed your program with kprintf's and see your program's progress on the terminal. I have a bunch of assembly macros to send stuff out to the parallel port. Mail to me if you want them. If you program a lot, I'd recommend Metascope. This has been worth every penny for me, even though it's a pain to use with multitasking programs. Steve Schoettler ( mail by way of hplabs!amdahl!kim who can forward to me ) -- UUCP: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (01/15/87)
In article <2846@gitpyr.gatech.EDU> wutka@gitpyr.gatech.EDU (Mark Wutka) writes: >Anybody know of a good debugger that is inexpensive (VERY inexpensive) ? > >I have been toying around with the Macro Assembler and I can't even open >the Intuition Library. It bombs when I jump to OpenLibrary and I can't >figure out why. I can't even tell if it is the jump that does it or if >it bombs within OpenLibrary since I can't tell where my program is >loaded into memory so I can't track it very well. Anybody know of a debugger >that would help ? > Metascope by Metadigm is good. Meanwhile, here is one of my clumsy assembler examples. It really didn't need an OpenLibrary since it only uses Exec and Dos calls and both of those libraries are opened by the startup code it is linked with. But I added code to open and close graphics.library just to show you how to do it. The example is meant to demo how to Open a file (PRT: in this case), Write() to it, fprintf() to it, and Close it. It also shows how to use printf() and getchar() from assembler. (Handy for debugging) Please excuse any stupid code. I use 68000 assembler very little and I don't yet know all of the instructions. carolyn *------------------------------------------------------------------------- * * assorted.asm --- Simple printer output using PRT: file * Shows use of Open(), Write(), Close() and also * interfaces with Amiga.lib's printf(),fprintf(), and getchar() * Also shows use of OpenLibrary() * Must be linked with startup code (AStartup.obj) * INCLUDE "exec/types.i" INCLUDE "libraries/dos.i" * Macros * LREF MACRO XREF _LVO\1 ENDM * This one calls a library routine * You must place the library's base in a6 before using this LJSR MACRO JSR _LVO\1(a6) ENDM * Imported Labels * XREF _AbsExecBase XREF _DOSBase * Opened by startup code XREF _printf XREF _fprintf XREF _getchar LREF OpenLibrary LREF CloseLibrary LREF Open LREF Write LREF Close LREF Delay * Exported Labels * XDEF _main * AStartup.obj does JSR to this label XDEF _GfxBase * For demo of OpenLibrary CODE * Code * _main: movem.l d0/a6,-(a7) Save the registers move.l a7,myInitSP Save initial stack pointer * Demo Opening a Library * move.l _AbsExecBase,a6 Exec Base to a6 move.l #0,d0 Version to d0 lea GfxName,a1 Ptr to library name in a1 LJSR OpenLibrary Call OpenLibrary move.l d0,_GfxBase Ptr to _GfxBase bne gfxOK Valid base - continue lea.l erOpenLib,a0 Else ptr to error message move.l a0,erStr Store in erStr bra cleanup Abort * Demo _printf the base address * gfxOK: move.l a7,tempSP Save stack pointer move.l _GfxBase,-(a7) Push _GfxBase pea.l libstr Push address of format string jsr _printf Print it move.l tempSP,a7 Fix stack move.l #1,d0 Print debugging variables jsr mydebug move.l _DOSBase,a6 Was opened by AStartup.obj lea.l prName,a0 Addr of file name PRT: move.l a0,d1 Place in d1 move.l #MODE_NEWFILE,d2 New file LJSR Open Attempt Open move.l d0,prFile Store filehandle bne.s dowrite Branch if OK lea.l erOpenPr,a0 Addr of Open error msg move.l a0,erStr Store in erStr bra cleanup Go to cleanup dowrite: ;--- Try a simple Write() to printer file move.l _DOSBase,a6 (not really needed - still there) move.l prFile,d1 File handle lea.l testStr,a0 Address of string or buffer move.l a0,d2 Put in d2 move.l #12,d3 Length of testStr LJSR Write Write string to file move.l d0,wLen Write Length (-1 = error) bpl dofprintf Branch if OK lea.l erWrite,a0 Ptr to error message move.l a0,erStr Store in erStr bra cleanup Abort dofprintf: ;--- Try formatted write to printer using _fprintf() move.l testNum2,-(a7) Push variable 2 on stack move.l testNum1,-(a7) Push variable 1 on stack pea.l testFStr Push addr of format string move.l prFile,-(a7) Push printer file handle jsr _fprintf Formatted print to printer addq.l #8,a7 Fix the stack (8 + 8 = 4 longs) addq.l #8,a7 (could have saved/restored instead) move.l #0,erStr All OK - error string ptr = NULL cleanup: move.l erStr,d0 Any errors ? beq.s cleanup2 No move.l erStr,-(a7) Push ptr in erStr on stack jsr _printf Print error string addq.l #4,a7 Fix stack cleanup2: move.l #2,d0 Print debugging variables jsr mydebug move.l prFile,d1 If printer file was not opened beq.s cleanup3 skip the Close move.l _DOSBase,a6 Else Close it LJSR Close movea.l _GfxBase,a1 If graphics.library was not opened beq.s cleanup3 skip the CloseLibrary move.l _AbsExecBase,a6 Else ExecBase to a6 LJSR CloseLibrary and CloseLibrary cleanup3: move.l #3,d0 Print debugging variables jsr mydebug pea.l pressStr Push addr of pressStr jsr _printf Print prompt string addq.l #4,a7 Fix stack jsr _getchar Waits for a <RETURN> addq.l #4,a7 Throw away char returned on stack move.l myInitSP,a7 Restore initial stack pointer movem.l (a7)+,d0/a6 Restore registers rts mydebug: move.l a7,tempSP Save stack pointer move.l a7,-(a7) Push stack move.l prFile,-(a7) Push prFile move.l _DOSBase,-(a7) Push _DOSBase move.l d0,-(a7) Push checkpoint pea.l debugStr Push debug string jsr _printf Print the pushed variables move.l tempSP,a7 Restore stack pointer rts DATA CNOP 0,4 prFile DC.L 0 CNOP 0,2 _GfxBase DC.L 0 CNOP 0,2 testNum1 DC.L 1 CNOP 0,2 testNum2 DC.L 2 CNOP 0,2 testStr DC.B 'Test string',10,0 CNOP 0,2 testFStr DC.B 'num1 = %ld num2 = %ld',10,0 CNOP 0,2 pressStr DC.B 'Press <RETURN> to exit.',10,0 CNOP 0,2 libstr DC.B 'The library base is $%lx',10,0 CNOP 0,2 debugStr DC.B 'checkpoint=%ld stack=%ld prFile=%ld _DOSBase=%ld',10,0 CNOP 0,2 prName DC.B 'PRT:',0 CNOP 0,2 GfxName DC.B 'graphics.library',0 * Error messages * CNOP 0,2 erOpenPr DC.B 'Can not open printer',10,0 CNOP 0,2 erWrite DC.B 'Error writing to printer',10,0 CNOP 0,2 erOpenLib DC.B 'Can not open library',10,0 * Uninitialized variables * CNOP 0,2 wLen DS.L 1 CNOP 0,2 erStr DS.L 1 CNOP 0,2 myInitSP DS.L 1 CNOP 0,2 tempSP DS.L 1 END -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
gnu@hoptoad.uucp (John Gilmore) (01/18/87)
The GNU project has been shipping a public domain source level debugger
for C programs, called "gdb" (GNU DeBugger). I know it runs on Suns
and Vaxes. I have an old copy lying around, but you should get the latest
copy from the Free Software Foundation. (If there isn't a volunteer with
Arpanet access and an Amiga, to move it to Amiga floppies, I could grab it
from the Arpanet and uucp it to Fred Fish. Let's see if anybody wants it,
first, and if a volunteer pops up.)
Being a source level debugger, it requires that the compiler output a
symbol table and such; and it needs to be taught about the particular
format of the symbol table for *your* compiler. It currently knows
Sun and Vax "dbx" symbol tables, and its own format, which can be produced
by the public domain GNU C compiler (being tested now). I haven't used
gdb myself, but have watched RMS use it, and it's roughly the same power
as Unix "dbx" -- you don't see the machine language at all unless you
want to; you just work in C.
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu
/* No comment */fnf@mcdsun.UUCP (Fred Fish) (01/19/87)
In article <1672@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > [info about GNU project gdb] (If there isn't a volunteer with >Arpanet access and an Amiga, to move it to Amiga floppies, I could grab it >from the Arpanet and uucp it to Fred Fish. Let's see if anybody wants it, >first, and if a volunteer pops up.) I have a copy of version 1.10, probably not the latest. Most GNU things seem to autoincrement weekly :-) (heh, better than never getting fixed!) Anyway, if anyone is serious about attempting a port, and has no easy way to get the latest and greatest on Amiga floppies, contact me and I'll see that you get a copy. -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
aburto@marlin.UUCP (Alfred A. Aburto) (01/21/87)
In article <1234@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: > > The example is meant to demo how to Open a file (PRT: in this case), >Write() to it, fprintf() to it, and Close it. It also shows how to use >printf() and getchar() from assembler. (Handy for debugging) > > Please excuse any stupid code. I use 68000 assembler very little and >I don't yet know all of the instructions. > > carolyn > ********************************** Thanks alot for the example assembly program. It was not clumsy, and there was nothing 'stupid' about it. Example programs like this are very helpful and they are appreciated. Like to see more. You mentioned the device.library in one of your earliar messages. The ROM Kernal manual has has a very good example showing how to output text to a window but no example for getting keyboard inputs. An assembly example here would be helpful. Al Aburto ***********************************
root@sbcs.UUCP (Root) (01/21/87)
> In article <1672@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > > [info about GNU project gdb] (If there isn't a volunteer with > >Arpanet access and an Amiga, to move it to Amiga floppies, I could grab it > >from the Arpanet and uucp it to Fred Fish. Let's see if anybody wants it, > >first, and if a volunteer pops up.) > > I have a copy of version 1.10, probably not the latest. Most GNU things > seem to autoincrement weekly :-) (heh, better than never getting fixed!) > Anyway, if anyone is serious about attempting a port, and has no easy way to > get the latest and greatest on Amiga floppies, contact me and I'll > see that you get a copy. > > -Fred > -- I compiled up a copy of gdb for the Amiga - after looking through the various undefined symbols, a few caveats come to mind for those considering a port: 1. The version I have uses a yacc parser, so be sure to pick up a copy of Bison before you start your porting effort. Guess Fred has a working copy on one of his later disks. Fred? 2. Call up Perry (ASDG) and order up some more memory for your machine - the executable generated by our Sun cross compiler system is roughly 250K bytes (text/bss/data) + whatever dynamic memory required. 3. Be prepared to resolve some of the more arcane Unix calls, for example, ptrace(). Actually ptrace() isn't all that bad compared to vfork/wait, etc. Yes, you probably could Amiga'ize the code completely, though this is unadvisable since as Fred mentioned, the code is being improved constantly. 4. Also be aware that you will have to "know thy compiler" w.r.t. it's symbol table output - is this sort of information documented (available?) in Manx/Lattice? As for gdb itself, what can I say? It is well worth the effort! Rick Spanbauer PS. Anyone have an X windows front end for gdb?