|Re: [hatari-devel] Re: Hatari debugging help with WinUAE CPU core|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I just commited the new code with the changes you requested.
I added also (2 liner) preliminary exception debugging
support to WinUAE CPU core, but WinUAE CPU core needs still
improvements to its exception handling:
* the questions I had about place of VDI/BIOS handling
& them missing from MMU exceptions handling
* Instead of calling Reset_Cold()/m68k_reset()/uae_reset()
directly from newcpu.c, show user a notice (dialog)
about what happened and let user do the reboot, like
happens with old UAE CPU core
In the old UAE CPU core, I wonder should the "address error
during exception 2/3" error also do:
regs.intmask = 7;
Like the double bus error case does?
On maanantai 27 tammikuu 2014, Nicolas Pomarède wrote:
> Le 24/01/2014 22:55, Eero Tamminen a écrit :
> >> maybe you could use "--exception_debug" instead ?
> > That's way too long, it would make Hatari "--help" output too
> > wide for 80 cols console. If you want it changed, please suggest
> > something more specific that's not longer than "--exceptions"
> > (current option& help already goes to 80 cols).
> > Already existing --debug options has also very broad meaning,
> > how I should rename that ?
> Yes, '--debug' is not very self explanatory, especially as it has
> nothing to do with "debugging" directly, but more with breaking on "bus
> error" and "address error" (it's a historical option where emulation was
> less precise)
> Maybe "--debug" could be removed, I doubt the change will affect many
> Then it could be merged with "--exceptions" into "--debug-execpt", which
> would fit the 80 char column width :
> --run-vbls <x> Exit after x VBLs
> --debug-execpt <mask> xxxxx
> Regarding this 80 columns limitation, do we still need it ? I don't
> think so, we could relax it a little up to 100 chars, nobody is running
> hatari from plain fixed 80x25 tty :)
> Any console window can be resized in width to see more chars (and 80
> chars is really short, I doubt any user running hatari from a console
> has so short windows).
> For example, take a look a "gcc --help", it goes to 115 column in my
> french locale settings.
> >> if ( ( nr>=2 )&& ( nr<=11)&& ( ExceptionDebugMask ) )
> >> DebugUI_Check_Interrupt_Mask ( nr );
> > I'm assuming you're more worried about modifying existing code
> > lines than adding single block of code there. If that's true,
> > does the attached patch look better?
> It's shorter, but I'd like better something where all extra code/text
> goes into the *.c debug files :
> if (ExceptionDebugMask && nr > 3 && nr < 9)
> DebugUI_Exceptions ( nr );
> The CPU emulation part is really complex, sometimes hard to follow and
> the less "distraction" there is, the better it is, so I would prefer if
> inserted debug code could be limited to 2 lines : one "if" statement and
> one function call.
> The other modifications in newcpu.c look ok to me, it's just the one at
> "@@ -1049,6 +1052,22 @@" that should be changed.
> > And why there's debugger activation in Exception(),
> > instead of in exception_debug() that's called from
> > above listed functions (i.e. like it's done in old
> > UAE CPU core)?
> > (Exception handling there looks completely different, i.e. I don't
> > think adding exception debugging there to affect merging in either
> > direction.)
> cpu/newcpu.c does not have the same logic has uae-cpu/newcpu.c, so I
> guess that when Laurent added changes to improve the falcon emulation,
> not all code in uae-cpu was merged into the new cpu core as some cpu
> structures are not the same and it's harder to backport the code.
> Unfortunately, I don't have time to work on this now, so I think it will
> stay this way for a moment (unless someone with good cpu knowledge wants
> to change this without breaking everything :) ).
> But in the end, as Doug asked for such exceptions mask to help debugging
> his code, if this new --debug-except is only present in the old cpu
> core, I'm afraid it won't be very useful to him, as the old core is not
> the recommended one for falcon emulation ?