| Re: [hatari-devel] symbols not always loaded when entering debugger ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 11/16/2017 12:18 PM, Nicolas Pomarède wrote:
Le 16/11/2017 à 00:59, Eero Tamminen a écrit :
I improved that a bit. Instead there's now a command:
symbols resident
[...]
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 ?
Maybe after it's been used for few weeks and there are no
problems with it. I'm not yet convinced that it's really
needed (except in some rare cases).
Having to create various ini file and use --parse option is not
straightforward to user.
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.
My "build chain" is simple at the moment :
run vasm
run "hatari test.prg"
Just replace "hatari" with one-line script providing relevant
Hatari options for debugging?
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).
[...]>> 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.
Your test.prg and TOS 1.62 work exactly like EmuTOS in my example.
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).
(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.
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.
[1]
Why you intentionally want to make things harder to debug,
why not just use the --debug-except option?
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. :-)
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
- Eero