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

[ Thread Index | Date Index | More Archives ]

Le 16/11/2017 à 21:01, Eero Tamminen a écrit :

Trivial script adding few command line args for Hatari should
be an obvious thing to do for a programmer, once he's aware [1]
of what's needed.  Especially as this is not the only thing
programmer may want to set up in debugger.

[1] Documentation may need "Best Practices" section for debugging.

I know that I can use a script, but it's not the point ; there're several people that do real use of Hatari to debug their code (me included, but that's not the point) who consider the current symabol handling is cumbersome and not straightforward.

You can tell people to read the doc, but it doesn't work ; when your program crashes, you want to debug it quickly, not trying to figure where are the symbols or how to load them again.

I mean, I'm a developer for Hatari, and even I am sometimes lost in the options and need to look at the code to be sure of how to do it. At first I didn't understand why my symbols were there and after a crash they're not there anymore and spent sometimes looking for what I did wrong.

Your test.prg and TOS 1.62 work exactly like EmuTOS in my example.

that's because you added extra option to intercept such or such exception, which is not the default I gave in my example of just runing "hatari test.prg"

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.

You didn't ask Hatari to invoke debugger on exceptions with
--debug-except option, like I did (see terminal copy-paste in
my previous mail).

But I don't want to invoke debugger on bus or address error, because maybe I'm writing a protection for a demo that will do exception on purpose.

Err... If I got it right, first you "complain" about things that
happen when program returns to GEM (symbols get lost), then you
argue that you don't want to use the option [2] that invokes debugger
instead of allowing program to return to GEM, and then you say that
things are OK as long as program doesn't return to GEM???

I'm lost on what you're trying to say.

To make it simple :)
- I want symbols to be loaded automatically at start if they are present in the .prg - I don't want the symbol table to be removed automatically later when PTERM or others OS functions are called. Only if another program is loaded later then the symbols table could be replaced by the one of this new program.
 - all these by not adding specific options :)

And note that in my case, I never said program returned to gem, it display 3 bombs and that's it, computer is "stalled" and on a normal STF/STE the only solution would be to reset. I could admit that if GEM desktop was really displayed after the crash then it could be normal that memory is cleaned and symbols are lost, but it's not the case, when bombs are displayed, the computer must be reset, so I don't see why sympols would be removed.

Why you intentionally want to make things harder to debug,
why not just use the --debug-except option?

See above, some exceptions can be on purpose, so I don't want to provide some extra options to filter some of them and keep the others.

to quote you "why do you want to make things more complicated to run by adding tons of options", when I think this should be the default when just running "hatari test.prg" :)

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.

For fast coding environment, I'd recommend using EmuTOS.

It boots *much* faster than normal TOS and is functionality-
and usability-wise in latest snapshots on par with TOS <= 3.x.
And also solves your problem. :-)

I have nothing against emutos but in some case it's not an option, I want to be as close as possible to my real STF/STE.

As a summary, there are *3* different, pretty trivial ways
to get debug symbols when things crash:
1. Use EmuTOS instead of normal TOS during development
    (and as otherwise, validate end result with other TOS versions)
2. ask Hatari to invoke debugger on exceptions
    (option: --debug-except autostart,all)
3. Use "symbols resident" command.  If you don't want to
    type it yourself, automate that with one-liner shell
    & debugger scripts

4 - listen to users' request and make option 2. and 3. the default :)

Hatari's debugger/profiler has great options and values, some complex cases require more options and that's normal, but I think that the "entry cost" for simple tasks is too high and most users will stop there, which is a shame. Providing more straightforward defaults would certainly allow more users to discover and appreciate this part of Hatari.


Mail converted by MHonArc 2.6.19+