|Re: [hatari-devel] symbols not always loaded when entering debugger ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 16/11/2017 à 00:59, Eero Tamminen a écrit :
Now, if the prgres allow to achieve the same result, it's not
necessary > to load symbols at start.
I improved that a bit. Instead there's now a command:
Besides letting symbols persist after program exits, it
will automatically load them at program exit, if they
haven't been loaded yet.
(Improvement is that you can do it before program is run,
and you don't need to do it separately for every started
If you want that behavior to be the default, run Hatari
with the following option:
And put that command to the debugger.ini file (along
with any other debugger setup you like).
but why not making this the default and do a "noresident" option for
example for those that really don't want symbols to be loaded ?
Having to create various ini file and use --parse option is not
straightforward to user.
My "build chain" is simple at the moment :
run "hatari test.prg"
From this I'd like symbols to be automatically handled if they are
present in test.prg (and I guess from various other mails that most
people expect that too).
There could be a default to load symbols if present and keep them
resident and then add a message in the output :
"xxx symbols loaded from yyy.prg ; use option noresident if you don't
want symbols to be loaded automatically and resident" (for example)
The symbols are there, after I press space and there's
What do you get with the same Hatari options?
If one continues from the address error, the program is terminated
and *then* its symbols aren't anymore valid and Hatari removes them.
The difference is that you used emutos for your test and that I used a
standard TOS (as my in STF/STE). And while emutos will not do a PTERM,
standard TOS does a PTERM :
Bus Error at address $ffff8a00, PC=$fc0ee0 addr_e3=fc0ee2 op_e3=4a68
GEMDOS 0x4B Pexec(0, "C:\TEST.PRG", "", 0x0) at PC 0xFA002A
GEMDOS 0x3D Fopen("C:\TEST.PRG", read-only) at PC=0xFA002A
-> FD 64 (read-only -> read-only)
GEMDOS 0x4B Pexec(7, 0x0, 0xa542, 0x0) at PC 0xFA002A
GEMDOS 0x4B Pexec(5, 0x0, 0xa542, 0x0) at PC 0xFA002A
GEMDOS 0x3E Fclose(64) at PC 0xFA002A
Address Error at address $1001, PC=$128d4 addr_e3=128d6 op_e3=4e75
GEMDOS 0x4C Pterm(-1) at PC 0xFA002A
Even with normal TOS, Pterm() happens after address error, so you
still have symbols when the exception invokes the debugger???
No, with tos 1.62 for example, symbols are not there anymore with tht
test.prg I sent earlier that does an address error. You can try it and
maybe see at which point symbols get unloaded, but that's different from
what you saw with emutos.
If the crash is in the program itself, symbols are still there when
debugger is invoked. Only after you continue program execution,
TOS will terminate the crashed program.
See my test.prg, you will see it's not the case. An address error will
cause a jump into TOS handler for this exception, display 3 bombs on
screen and at this point if you press alt+pause, symbols are not there
(Debugging things long time after the bug has occurred is IMHO often
wasted time. Just set suitable exception / breakpoint to invoke
the debugger, and debug the issue when it actually happens.)
You don't know that, it depends on each case ; maybe you're thinking C
oriented level where library calls could call each other and it's hard
to go back to the source of the crash.
But when coding in asm, you know your code ; if I write a scrolling
routine for example and there's a crash, I'd like to be able to access
the sympols list to see what was the content of the variables / memory
addresses used by this scrolling routine, it doesn't matter if I enter
the debugger long after the crash, as long as the program is still
crashed and didn't return to gem, I know most of memory content will
still be there.
For the authentic experience, they could use the same (native)
debugger they used on their original STF/STE. :-)
But that's not the point, the point here it to be able to code on a PC
and run hatari with the resulting .prg to have a very fast coding
I don't necessarily want to use all the features of monst, I want to run
my .prg, see if it works on screen, and in the case where it would
crash, be able to see the symbol lists to inspect memory content at the
time it crashed. All that without adding option ;-)