Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
08818 Crash/Freeze Critical (emulator) Always Feb 10, 2024, 03:20 Feb 21, 2024, 03:51
Tester Roberto Fresca View Status Public Platform MAME (Self-compiled)
Assigned To AJR Resolution Fixed OS Windows 10/11 (64-bit)
Status [?] Resolved Driver
Version 0.258 Fixed in Version 0.263 Build 64-bit
Fixed in Git Commit 9d36a10 Github Pull Request #
Summary 08818: magicrde: PIC16F54 debug problems
Description The problem is if you try to use watchpoints on the SFR's (special function registers) range.
WPoint (w) on register 0, breaks MAME going directly to a segfault.

Also putting WPoints for R or W on registers 1 to 8 have no effect, since they don't stop the execution once reached.
Steps To Reproduce Run MAME -d magicrde
Once in the debugger, press F6 to execute to the PIC.
Once in the PIC, write:

wpd 0, 1, w
g
This will crash MAME with a segfault.

but...

wpd 1, 8, w
wpd 1, 8, r
These don't work, at all. The WP is not stopping if these registers are read or written.
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems magicrde
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
3
User avatar
No.21958
Robbbert
Senior Tester
Feb 10, 2024, 04:13
Crash confirmed.

-----------------------------------------------------
Exception at EIP=00007ff790fba547 (pic16c5x_device::execute_run()+0x00a7): ACCESS VIOLATION
While attempting to read memory at 0000000000000003
-----------------------------------------------------
RAX=0000000000000000 RBX=000001e1d59ae490 RCX=000001e1dab2db40 RDX=0000000000000000
RSI=00007ff79dc14d20 RDI=000001e1d59b1fe8 RBP=00007ff79dc14ba0 RSP=0000004838b099b0
 R8=000001e1d59ae490 R9=0000000000000102 R10=0000000000000001 R11=00001ffe49b7681c
R12=0000000000000028 R13=000000000000003b R14=00007ff79d8a5520 R15=0000004838b09db0
-----------------------------------------------------
Stack crawl:
  0000004838b09a00: 00007ff790fba547 (pic16c5x_device::execute_run()+0x00a7)
  0000004838b09a70: 00007ff78fe7ebcd (device_scheduler::timeslice()+0x05fd)
  0000004838b09bf0: 00007ff78fe7b8ff (running_machine::run(bool)+0x01bf)
  0000004838b0f120: 00007ff79365daab (mame_machine_manager::execute()+0x024b)
  0000004838b0f510: 00007ff797855736 (cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x03e6)
  0000004838b0f7f0: 00007ff797855d5b (cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x007b)
  0000004838b0f850: 00007ff793658269 (emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x0029)
  0000004838b0fc10: 00007ff7994fd6d3 (luaopen_lfs+0xc284d3)
  0000004838b0fce0: 00007ff78b5413b1 (__tmainCRTStartup+0x0231)
  0000004838b0fd10: 00007ff78b5414e6 (mainCRTStartup+0x0016)
  0000004838b0fd40: 00007fffff657344 (BaseThreadInitThunk+0x0014)
  0000004838b0fdc0: 00007ff8006626b1 (RtlUserThreadStart+0x0021)
User avatar
No.21959
hap
Developer
Feb 12, 2024, 11:12
edited on: Feb 12, 2024, 11:14
Yup, I confirmed with hh_pic16.cpp "touchme" (easier to reproduce since it has a single CPU).
The not-functional but not-crashing watchpoint issue could be a different cause.
User avatar
No.21960
AJR
Developer
Feb 13, 2024, 01:19
edited on: Feb 13, 2024, 01:22
I remember MAME's pic16c5x and pic16c62x cores handling register file accesses in a particularly ugly and bad way. I began a WIP to clean them up many years ago, but it only actually covered the latter core, was never tested properly, and ended up being lost when my old computer died.

There's a good argument that wpd 0, 1, w *shouldn't* do anything useful here (though it also shouldn't crash), because MAME's watchpoints are designed to trap physical memory addresses and INDF is "not a physical register" as Microchip's manuals consistently state. In my pic17 and rii CPU cores, I translate INDF0 and INDF1 references before attempting to access internal memory.