Hi Toni,
Been using this more recently, great work as always, but I noticed a couple of issues:
1. WinUAE crashes if you trying to allocate a very large amount of memory (e.g. $40000000, but I think in general more than fits into debug memory). Repro in attached "alloc.exe"
I also think that trying to allocate an "abnormally" large amount of memory (say >=64MB) should cause a debug break, since it's going to be an error in 99.9% of cases. In the case I was looking at the upper word of D0 was junk when AllocMem was called.
2. It seems like something can go awry after reporting an error. I think it might be related to interrupts, but I'm not sure. In attached "test.exe" I continue with "g<enter>" a couple of times and it ends up executing "val" as an instruction. (Might relate to my next point)
3. Code like:
Code:
func:
addq.w #1,val
rts
val: dc.w 0
is extremely common, even if it makes your job harder
. It would be nice if the SMC warnings could be inhibited on their own without affecting other memory warnings (i.e. a separate bit in inhibit_break for SMC). It seems like you get a hit for both the instruction fetch from modified memory, and an invalid access when updating "val".
4. HUNK_DREL32 (1015) doesn't seem to be supported - vasm will output these when not assembling with -kick1hunks. "drel32.exe" attached.
I'm testing by running
Code:
winuae64.exe -cfgparam=quickstart=A1200,3 -s filesystem2=rw,DH0:DH0:c:\Temp\uaedbg\hd,0 -s uaehf0=dir,rw,DH0:DH0:c:\Temp\uaedbg\hd,0 -cfgparam=debug_mem=true -G
Where the HD directory just contains the attached files.
Once again thanks for your hard work, and obviously this is not any kind of priority. It's still super useful.