Basics of debugging ASM in WinUAE?

[bodhi]

Hi,

Debugging ASM code in WinUAE, how is it done?

For someone new to Amiga ASM, this is quite confusing. I understand the basics of high level language debugging on the PC and from what I can imagine the ideas are similar for ASM debugging: set a point in your code where you want a break(point), and then manually step through each command/function while watching variables, status regs, etc to identify incorrect input/output of various functions.

Since beginning to learn ASM on Amiga, I'm seeing that some proper debugging skills might be useful. Just being able to look at a data reg befor the code explodes could answer some questions and help track down the problem.

So how do I do it using the WinUAE and its debugger? For example, I have some buggy code and a rough idea where the problems in the code begin and I want to set a "breakpoint" at the point just before the code crashes and bring up the monitor/debugger so that I can watch certain registers, or values of memory addresses. What do I do in my code to trigger this break point? How do I mark a variable/memory address so that I can "watch" it in the debugger? How do I get symbols out to the debugger to make code easier to read in the debugger? Also any other useful information? Is there a manual for the debugger somewhere that I've missed, a good tutorial?

anything?

[pmc]

I don't know about the WinUAE debugger and haven't ever really used it but... I have debugged lots of asm code.

I've always just used the debugger (MonAm) that is available with the assembler I use (GenAm) that are both bundled together as Devpac.

You can think of MonAm as analagous to a modern IDE debugger in that it allows all the things that you describe - you can load in your code, set breakpoints, single step, watch registers etc. etc.

There is a .pdf manual available for Devpac that contains instructions for how to use MonAm too.

I've mentioned the tools available in Devpac as that's what I've used but there are a few other assemblers worth using (AsmOne anyone...? Sting...? ) that also have their own debuggers that might be more to your taste that you could try too.

[BippyM]

here's the debugger help (type h lol)

HELP for UAE Debugger
         -----------------------

  g [<address>]         Start execution at the current address or <address>.
  c                     Dump state of the CIA, disk drives and custom registers.
  r                     Dump state of the CPU.
  r <reg> <value>       Modify CPU registers (Dx,Ax,USP,ISP,VBR,...).
  m <address> [<lines>] Memory dump starting at <address>.
  d <address> [<lines>] Disassembly starting at <address>.
  t [instructions]      Step one or more instructions.
  z                     Step through one instruction - useful for JSR, DBRA etc.
  f                     Step forward until PC in RAM ("boot block finder").
  f <address>           Add/remove breakpoint.
  fa <address> [<start>] [<end>]
                        Find effective address <address>.
  fi                    Step forward until PC points to RTS, RTD or RTE.
  fi <opcode>           Step forward until PC points to <opcode>.
  fp "<name>"/<addr>    Step forward until process <name> or <addr> is active.
  fl                    List breakpoints.
  fd                    Remove all breakpoints.
  fs <val> <mask>       Break when (SR & mask) = val.
  f <addr1> <addr2>     Step forward until <addr1> <= PC <= <addr2>.
  e                     Dump contents of all custom registers, ea = AGA colors.
  i [<addr>]            Dump contents of interrupt and trap vectors.
  il [<mask>]           Exception breakpoint.
  o <0-2|addr> [<lines>]View memory as Copper instructions.
  od                    Enable/disable Copper vpos/hpos tracing.
  ot                    Copper single step trace.
  ob <addr>             Copper breakpoint.
  H[H] <cnt>            Show PC history (HH=full CPU info) <cnt> instructions.
  C <value>             Search for values like energy or lifes in games.
  Cl                    List currently found trainer addresses.
  D[idxzs <[max diff]>] Deep trainer. i=new value must be larger, d=smaller,
                        x = must be same, z = must be different, s = restart.
  W <address> <values[.x] separated by space> Write into Amiga memory.
  W <address> 'string' Write into Amiga memory.
  w <num> <address> <length> <R/W/I/F/C> [<value>[.x]] (read/write/opcode/freeze/mustchange).
                        Add/remove memory watchpoints.
  wd [<0-1>]            Enable illegal access logger. 1 = enable break.
  S <file> <addr> <n>   Save a block of Amiga memory.
  s "<string>"/<values> [<addr>] [<length>]
                        Search for string/bytes.
  T or Tt               Show exec tasks and their PCs.
  Td,Tl,Tr,Ts,Ti,TO     Show devices, libraries, resources, residents, interrupts, doslist.
  b                     Step to previous state capture position.
  M<a/b/s> <val>        Enable or disable audio channels, bitplanes or sprites.
  sp <addr> [<addr2][<size>] Dump sprite information.
  di <mode> [<track>]   Break on disk access. R=DMA read,W=write,RW=both,P=PIO.
                        Also enables level 1 disk logging.
  did <log level>       Enable disk logging.
  dj [<level bitmask>]  Enable joystick/mouse input debugging.
  smc [<0-1>]           Enable self-modifying code detector. 1 = enable break.
  dm                    Dump current address space map.
  v <vpos> [<hpos>]     Show DMA data (accurate only in cycle-exact mode).
                        v [-1 to -4] = enable visual DMA debugger.
  ?<value>              Hex ($ and 0x)/Bin (%)/Dec (!) converter.
  x                     Close debugger.
  xx                    Switch between console and GUI debugger.
  mg <address>          Memory dump starting at <address> in GUI.
  dg <address>          Disassembly starting at <address> in GUI.
  q                     Quit the emulator. You don't want to use this command.

[Toni Wilen]

UAE debugger is designed (if you can call it being "designed"..) for debugging programs that take over the system and it is not meant to be user friendly

f, w and t are the most important break point commands.

[Apollo]

Have been working with the UAE debugger and I'm getting used to it. Here are my steps trying to solve serious problems (code which took over the system)

1. put a loop waiting for the left mousebutton right after the start of the code
2. put a string (dc.b. "[whatever]") near the location where I presume the faulty code
3. start the program, program stays in wait-loop
4. enter Shift-F12 starting the uae debugger
5. search for the string > s "[whatever] < in memory, at least one address should be found
6. disassembling the memory at given address, > d $xxxxxx <
7. searching for the spot where I want to have the breakpoint, setting the bp with > f $xxxxxx <
8. quit the uae debugger and continuing the emulation
9. hit the left mousebutton
10. when the program stops at the breakpoint I follow the program with > t < or > z < (tip, within a dbxx loop >z< completely handles the loop)
11. anything after this is more or less related to the error, usually I seach for wrong pointers or condition codes (a wrong test or branch maybe?)

[Toni Wilen]

Much faster method to "find" your code is to have instruction like clr.w $100 before the code you need to debug and use memwatch point to break when $100 is accessed (for example "w 0 100 2")

[bodhi]

pmc: I would prefer to use UAE's debugger as it'd be better for my Windows-based crossdev Notpad++/VASM way of doing things but MonAm is definitely an alternative option. Devpac is a really nice Amiga asm IDE. I used it for a bit before I decided on crossdev. Didn't use MonAm at the time but I had a little play around with it lastnight and, like you say, it works well when I give it a GenAm compiled binary.

Haven't tried it with one of my regular VASM compiled binaries yet, so I don't know if MonAm will have difficulty with VASM symbols, hunks, line numbers (for source level debugging), etc. I'm not sure if all that stuff (debug hunks,etc) is standard on Amiga - but VASM also has some Devpac compatibility options. I'll have play around with that a bit more and see if they work well together.

I also had a quick look at BDebug (by Ralph Schmidt), which looks great. Can't say how well it works in use yet but it has a really nice Intuition interface (I noticed I could set BPs, etc. by clicking on mem addresses/labels, nice!)

bippym: I needed the h++++ option that displays Apollo's post. Couldn't find it! Anyways, you're right, seems the help list really is all there is to it

Appolo: That's great, Just what I needed to get me going. Thank you very much. I followed your steps for a simple program and they work well. From what Toni says, UAE's debbugger was never designed for "friendly" debugging - I thought maybe there was a bunch of functionality just not officially documented. But your steps may be all I ever need to debug my simple code anyway, so I think it could still be useful.

Toni: You're right. w 0 100 2 removes the need for at least 3 of Appolo's steps. Nice tip, cheers!

[Lonewolf10]

Originally Posted by Toni Wilen

Much faster method to "find" your code is to have instruction like clr.w $100 before the code you need to debug and use memwatch point to break when $100 is accessed (for example "w 0 100 2")

Thanks Toni, that's a great tip

[dalton]

Is there any absolute address that you can use for this purpose, without risk?

[jotd]

$60 is the spurious interrupt vector. Never saw that activated... also if you don't have MMU a lot of zero page addresses are unused.

Oh and you can still write 0 in 0.

[roondar]

If you feel uneasy writing to system vectors or memory addresses you haven't allocated, you could also include a word of allocated space in your program and write to that. Then, after the program starts, use the debugger to locate the address you use to write.

That should be safe in all cases. However, the examples above will also work so you could just use them.

[meynaf]

Originally Posted by dalton

Is there any absolute address that you can use for this purpose, without risk?

You can use $100 with no problem, unless you're running Enforcer or a similar tool and flood the output by repeatedly accessing this address

[Thorham]

Originally Posted by meynaf

You can use $100 with no problem

Does $0 cause any problems (except Enforcer, etc)?

[meynaf]

Originally Posted by Thorham

Does $0 cause any problems (except Enforcer, etc)?

No problem that i know of, however the available area is very small (4 bytes), where the whole $100-$3FF can be used.

[Thorham]

Originally Posted by meynaf

No problem that i know of, however the available area is very small (4 bytes), where the whole $100-$3FF can be used.

Didn't know that, thanks. I always just put a pointer into $0.

[KONEY]

Originally Posted by Toni Wilen

Much faster method to "find" your code is to have instruction like clr.w $100 before the code you need to debug and use memwatch point to break when $100 is accessed (for example "w 0 100 2")

Can you help me with this? It works well but how do I get rid of it afterwards?

w <num> <address> <length> <R/W/I/F/C> [<value>[.x]] (read/write/opcode/freeze/mustchange).
Add/remove memory watchpoints.

Looks like it's possible (add/remove) but how exactly?

It keeps freezing at every frame

Thanks!

[Radertified]

w 0 100 2 - Add to watchpoint #0
w 0 - Remove watchpoint #0

w 1 100 2 - Add to watchpoint #1
w 1 - Remove watchpoint #1

etc

[KONEY]

perfect, thanks!

[phx]

fi <opcode>

is usually the best method to set a breakpoint for UAE in your code, if you select an opcode which appears nowhere else, like

exg a7,a7

=

fi cf4f

. This code would also have no effect on your program.

[mcgeezer]

The watch points are better to use in my opinion because you can filter on the types of operation and the source of it (CPU, BLIITER channel, COPPER etc).