Re: [hatari-devel] symbols not always loaded when entering debugger ?

[ Thread Index | Date Index | More 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:
     symbols resident

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
program instance.)

If you want that behavior to be the default, run Hatari
with the following option:
     --parse debugger.ini

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 vasm
 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
address error:

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", [0]"", 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 anymore.

(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 environment. 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 ;-)


Mail converted by MHonArc 2.6.19+