| Re: [hatari-devel] symbols not always loaded when entering debugger ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel 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.
[1]
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.
Nicolas