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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 16/11/2017 à 00:59, Eero Tamminen a écrit :
> Hi,
>
> > 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).

hi

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 ;-)

Nicolas