06 December 2020, 22:00 | #1 |
Registered User
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 301
|
Diagnosing MuForce hits from ROM code?
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: Code:
findhunkoffset wb2k_gcc 0 0x#### 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. Code:
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" |
06 December 2020, 22:23 | #2 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,960
|
Quote:
|
|
09 December 2020, 13:00 | #3 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
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.
|
12 December 2020, 21:48 | #4 | |
Registered User
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 301
|
Quote:
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. |
|
12 December 2020, 22:20 | #5 | |
Registered User
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 301
|
Quote:
Code:
C:SetPatch QUIET Run >NIL: <NIL: segtracker Code:
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 Code:
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 Code:
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. 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. |
|
13 December 2020, 00:30 | #6 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,960
|
If report is ok, then buggy instruction (byte read from zero page) must be at $3f01f6, or a few lines earlier.
|
13 December 2020, 06:49 | #7 |
Registered User
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 301
|
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. |
13 December 2020, 08:23 | #8 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 55
Posts: 1,960
|
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.
|
13 December 2020, 11:27 | #9 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
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.
|
14 December 2020, 16:10 | #10 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
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. Quote:
|
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Need help diagnosing my PAL Amiga 500+ | SamBushman | support.Hardware | 51 | 26 May 2023 22:53 |
using MuForce with a bridgeboard | SimonV | support.Hardware | 6 | 19 December 2019 18:47 |
Diagnosing Amiga 3000T display issue | dschallock | support.Hardware | 1 | 06 December 2019 07:05 |
Diagnosing A4000 instability (RAM?) | zero | support.Hardware | 4 | 15 July 2017 20:36 |
Help diagnosing Apollo 1240 Hardware Problem | beltrixx | support.Hardware | 41 | 06 July 2009 23:35 |
|
|