|Re: [hatari-devel] Hatari Debugger Symbols|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Samstag, den 14.12.2019, 02:08 +0200 schrieb Eero Tamminen:
> On 12/11/19 8:37 AM, Markus Fröschle wrote:
> > Nevermind, I think I found a workaround.
> > If I load my fVDI test program (the one that's supposed to trigger
> > fVDI bug) from floppy instead of from a GEMDOS emulated hard
> > Hatari appears to bypass auto symbol loading for that executable
> > retains the original fVDI symbols loaded previously.
> I think symbol unloading still happens if you have
> GEMDOS tracing enabled, and haven't enabled the
> resident option.
> Automatic symbol loading is possible only with
> GEMDOS HD emulation though, as that's the only
> way for Hatari to get access to the program's
> symbols data.
Thank you, Eero. I don't think I need any change in Hatari, the
workaround turned out to just suit my needs perfectly.
Since it wasn't immediately obvious (at least to me) how I could
suppress loading symbols from my "trigger" program, maybe it makes
sense to add a "debugging resident programs" recipe in the debugger
manual? This would be my suggestion, feel free to include it (as is or
modified as you see fit) in the manual, if you find it worthwile:
Retain symbols in resident programs
When debugging resident (TSR) programs (terminated with a Ptermres()
GEMDOS call), you'll probably have a 'trigger' program that invokes
some functionality in the TSR you want to debug. Loading your 'trigger'
program from a Hatari GEMDOS emulated drive will autoload its symbols,
thus replacing the symbols of your TSR (which you are really interested
in) you loaded previously.
You can work around this issue if you load your 'trigger' program from
another drive without GEMDOS emulation (e.g. a floppy image). This will
bypass the symbols autoload of the 'trigger' program and (provided you
have instructed the debugger to retain your TSR's symbols with the
'symbols resident' command before) allow symbolic debugging in the TSR.