English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 06 December 2020, 23:00   #1
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
Question 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####
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.

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"
Warty is offline  
Old 06 December 2020, 23:23   #2
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 52
Posts: 1,286
Quote:
Originally Posted by Warty View Post
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####
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.

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"
I suspect you passed wrong value for A0 ($36). You can check/trace return offsets from stack to find which routine caused these hits.
Don_Adan is offline  
Old 09 December 2020, 14:00   #3
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 990
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.
Thomas Richter is offline  
Old 12 December 2020, 22:48   #4
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
Quote:
Originally Posted by Don_Adan View Post
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 is offline  
Old 12 December 2020, 23:20   #5
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
Quote:
Originally Posted by Thomas Richter View Post
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:
Code:
C:SetPatch QUIET
Run >NIL: <NIL: segtracker
And in user startup:
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
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:

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
The hunkoffset produces this:
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.
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.
Warty is offline  
Old 13 December 2020, 01:30   #6
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 52
Posts: 1,286
If report is ok, then buggy instruction (byte read from zero page) must be at $3f01f6, or a few lines earlier.
Don_Adan is offline  
Old 13 December 2020, 07:49   #7
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 95
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.
Warty is offline  
Old 13 December 2020, 09:23   #8
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 52
Posts: 1,286
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.
Don_Adan is offline  
Old 13 December 2020, 12:27   #9
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 990
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.
Thomas Richter is offline  
Old 14 December 2020, 17:10   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,826
Quote:
Originally Posted by Warty View Post
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.

Quote:
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.

Quote:
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.
phx is offline  
 


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 50 17 July 2020 16:55
using MuForce with a bridgeboard SimonV support.Hardware 6 19 December 2019 19:47
Diagnosing Amiga 3000T display issue dschallock support.Hardware 1 06 December 2019 08:05
Diagnosing A4000 instability (RAM?) zero support.Hardware 4 15 July 2017 21:36
Help diagnosing Apollo 1240 Hardware Problem beltrixx support.Hardware 41 07 July 2009 00:35

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.10397 seconds with 15 queries