Diagnosing MuForce hits from ROM code?

[Warty]

I'm working on bug fixes this weekend.

What's a good way to trace backwards from a ROM MuForce hit? If it was a hit directly from my code, I would do:

findhunkoffset wb2k_gcc 0 0x####

and have a good idea where in source code it was coming from.

But for hits that point to ROM, what options do I have? Is there anyway to find out which ROM function a given hit is coming from? Kind of like FindHunkOffset, but with the ROM specified? My assumption here is that I'm passing some bad values to an intuition function, but not knowing which function makes it tricky.

MuForce hit!
LONG READ from 00000036                        PC: 00FEA426
USP : 00363544 SR: 0010  (U0)(-)(-)  TCB: 00365698
Data: 00000036 00200010 00000001 0039004E 0000FFFF FFFFFFFF 00000001 00393AB4
Addr: 00000036 00364FD0 003648FC 00000036 00363640 0036358C 00209D0C 00202284
Stck: 00364D64 0036088C 00FEA310 00364E5C 00364D64 0036088C 00FEA2A6 00364D64
Stck: 00000002 00000001 003B65B4 0036159C 00FD433A 00364D64 003B4B30 00200864
----> 00FEA426 - "ROM - intuition 40.87 (9.9.2018)"  Hunk 0000 Offset 0001629E
Name: "Shell Process"  CLI: "wb2k_gcc"  

MuForce hit!
WORD READ from 00000046                        PC: 00FEA42A
USP : 00363544 SR: 0014  (U0)(-)(-)  TCB: 00365698
Data: 00000000 00200010 00000001 0039004E 0000FFFF FFFFFFFF 00000001 00393AB4
Addr: 00000036 00364FD0 003648FC 00000000 00363640 0036358C 00209D0C 00202284
Stck: 00364D64 0036088C 00FEA310 00364E5C 00364D64 0036088C 00FEA2A6 00364D64
Stck: 00000002 00000001 003B65B4 0036159C 00FD433A 00364D64 003B4B30 00200864
----> 00FEA42A - "ROM - intuition 40.87 (9.9.2018)"  Hunk 0000 Offset 000162A2
Name: "Shell Process"  CLI: "wb2k_gcc"

[Don_Adan]

Originally Posted by Warty

I'm working on bug fixes this weekend.

What's a good way to trace backwards from a ROM MuForce hit? If it was a hit directly from my code, I would do:

findhunkoffset wb2k_gcc 0 0x####

and have a good idea where in source code it was coming from.

But for hits that point to ROM, what options do I have? Is there anyway to find out which ROM function a given hit is coming from? Kind of like FindHunkOffset, but with the ROM specified? My assumption here is that I'm passing some bad values to an intuition function, but not knowing which function makes it tricky.

MuForce hit!
LONG READ from 00000036                        PC: 00FEA426
USP : 00363544 SR: 0010  (U0)(-)(-)  TCB: 00365698
Data: 00000036 00200010 00000001 0039004E 0000FFFF FFFFFFFF 00000001 00393AB4
Addr: 00000036 00364FD0 003648FC 00000036 00363640 0036358C 00209D0C 00202284
Stck: 00364D64 0036088C 00FEA310 00364E5C 00364D64 0036088C 00FEA2A6 00364D64
Stck: 00000002 00000001 003B65B4 0036159C 00FD433A 00364D64 003B4B30 00200864
----> 00FEA426 - "ROM - intuition 40.87 (9.9.2018)"  Hunk 0000 Offset 0001629E
Name: "Shell Process"  CLI: "wb2k_gcc"  

MuForce hit!
WORD READ from 00000046                        PC: 00FEA42A
USP : 00363544 SR: 0014  (U0)(-)(-)  TCB: 00365698
Data: 00000000 00200010 00000001 0039004E 0000FFFF FFFFFFFF 00000001 00393AB4
Addr: 00000036 00364FD0 003648FC 00000000 00363640 0036358C 00209D0C 00202284
Stck: 00364D64 0036088C 00FEA310 00364E5C 00364D64 0036088C 00FEA2A6 00364D64
Stck: 00000002 00000001 003B65B4 0036159C 00FD433A 00364D64 003B4B30 00200864
----> 00FEA42A - "ROM - intuition 40.87 (9.9.2018)"  Hunk 0000 Offset 000162A2
Name: "Shell Process"  CLI: "wb2k_gcc"

I suspect you passed wrong value for A0 ($36). You can check/trace return offsets from stack to find which routine caused these hits.

[Thomas Richter]

Turn on the "stacklines" option of MuForce so you get a full stack traceback. Also install SegTracker. This way, you will see where the code is coming from, including hunk and hunk offsets within your code.

[Warty]

Originally Posted by Don_Adan

I suspect you passed wrong value for A0 ($36). You can check/trace return offsets from stack to find which routine caused these hits.

What's the best way to get from a stack address, or any memory address, back to something that would identify to me what part of my code this is from? I am using the -g option with vbcc, and it appears to be embedding lots of debug info, but I don't know how to disassemble the code in memory, and have the symbols show up. Disclosure: I have lot more experience with 6502 8 bits than with the Amiga, especially when it comes to assembly: I don't work with 68K assembly at all, so my monitor knowledge is also weaker. I'm using "mon" / "Amiga Monitor", and it doesn't seem to have a command to show symbols in the hunk files. I can't predict where in memory the code will be loaded, so when I get a MuForce hit, I don't know how to see what bit of code that is.

If I load the executable within mon, I can see the addresses of course, but I get errors when I try to execute (g) the first seg.

[Warty]

Originally Posted by Thomas Richter

Turn on the "stacklines" option of MuForce so you get a full stack traceback. Also install SegTracker. This way, you will see where the code is coming from, including hunk and hunk offsets within your code.

I switched MuForce to show 4 lines of stack trace, but I'm not making good use of that yet. I have SegTracker running, at least, I assume it is. I'm using this in s/startup-sequence:

C:SetPatch QUIET
Run >NIL: <NIL: segtracker

And in user startup:

Run >NIL: <NIL: MuForce RAWIO VERBOSE STACKLINES=4 INTRO="MuForce hit!" 

Run >NIL: <NIL: Applications:dev/MuGuardianAngel/MuTools/MuGuardianAngel

;run <>NIL: PatchWork

;Run >NIL: Sashimi CONSOLE BUFK=64 NOPROMPT ASKEXIT ASKSAVE
Run >NIL: Sashimi >Applications:test/sashimi_out.txt

I get more information from the VBCC build than I do from the GCC (bebbo cross-compiler chain, not native Amiga gcc) compile, but for this example, which comes somewhere in the app shutdown sequence, and only pops up for the VBCC build:

MuForce hit!
BYTE READ from 00000000                        PC: 003F01F6
USP : 003B5A90 SR: 0008  (U0)(-)(-)  TCB: 003BC078
Data: 003B5B14 00000073 00000000 003B5B18 00000069 FFFFFFFF 00000012 00000000
Addr: 003B5B18 00000000 003EF024 00000000 003EF022 00400BB4 00200864 00202284
Stck: 00000000 00000000 00000000 20000000 40000000 60000000 00464E0C 00464E0C
Stck: 004018BC 003B9B74 00200864 73FC5C6E 003F0A54 000000D5 003EEF54 00FC5502
Stck: 00000000 00000000 0000FFFF 000000D5 00200864 003F0D10 00000000 00000000
Stck: 00000000 000018BC 004688FC 003EFB4A 00400BB4 003EF010 003B5B14 003EEFAC
----> 003F01F6 - "wb2k"  Hunk 0000 Offset 0000319E
Name: "Shell Process"  CLI: "wb2k"  Hunk 0000 Offset 0000319E

The hunkoffset produces this:

8.Applications:test> findhunkoffset wb2k 0 0x319e
Section 0, offset 0x0000319e is at
_vfprintf + 0x000006a6
in /Users/micahbly/eclipse-workspace-amiga/wb2k_gcc/app.c line 1109.

And line 1109 in app.c is the last line in the .c file (blank, to boot). If I do hunkfunc SHOWSYMBOL, that vfprintf bit there is solidly within what looks to be a block of C std functions. But is that a red herring?

If I m or d 3f01xx, it seems to have been unloaded, as it's all 0s.

If I knew where in memory the code was, I could put a breakpoint in mon, start the app quit sequence, and it would stop and let me examine everything.

[Don_Adan]

If report is ok, then buggy instruction (byte read from zero page) must be at $3f01f6, or a few lines earlier.

[Warty]

Thanks Don.

It actually was the vfprintf() function. I was passing it a null when doing a debug print, in the event the window being closed was a backdrop style window (no title set). The interesting thing is that VBCC compiled that "as is" (the printf printed nothing for the %s), while the gcc version printed (null) in the string. The GCC version was not getting this particular MuForce hit. They must use different C library functions or something.

I'm sure there's a way to know where in memory your code loaded... I would have traced back to the call that originated the problem using the stack and the seglist/hunk offsets. Maybe I can call SegTracker myself at startup and print out the segments, so I have them for when a MuForce hit occurs.
http://www.sinz.org/Michael.Sinz/Enf...Tracker.c.html

I think I'll probably just do "segtracker DUMP" after starting my app, so I have the offsets, when I am having a muForce problem.

[Don_Adan]

My favorite breakpoint for 68000 and Action Replay was file editor (FileMaster 2.2) and $60FE, it always works. You can replace first 2 bytes of code hunk with $60FE. Run program. Enter Action Replay, restore original code (in most cases it was $48E7) and trace your program, set normal breakpoints or $60FE when you want in code.

[Thomas Richter]

Add *more* stacklines. You currently have a hit in the standard library of the compiler, but you still need to find where from your code this call is made.

[phx]

Originally Posted by Warty

And line 1109 in app.c is the last line in the .c file (blank, to boot).

It's probably the last known line-debug info before the given offset. The clib was compiled without source level debugging information.

If I m or d 3f01xx, it seems to have been unloaded, as it's all 0s.

You can prevent unloading by adding an infinite loop at the end of your main() function. Otherwise it is pure luck what is left in memory.

An alternative approach, without using debug-info and findhunkoffset, would be to find the hunk-offset in the linker's map file (call vlink with -M option). It will show you to which object file the offset belongs. Then reassemble the object file.

If I knew where in memory the code was, I could put a breakpoint in mon, start the app quit sequence, and it would stop and let me examine everything.

Adding a breakpoint in vfprintf() doesn't help much, when you call it from multiple places. Thomas is right. In such a case you have to traverse the stack frame trace-back one or two levels deeper to find the caller.