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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 11/16/2017 11:06 PM, Nicolas Pomarède wrote:
[...]
> > 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.

Remember that you can toggle exception catching in debugger with:
	setopt -D


> > 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.

If you don't depend on TOS version specific memory locations
(which would be nowadays really bad thing to do in a program),
I think it should be indistinguishable from real ST/STE TOS.

If it's not, you can ask EmuTOS developers to fix that.
If your issue was real, soon you'll have a fixed version in
EmuTOS daily builds, so that it won't be an issue for you
anymore.  If issue was instead in your code, EmuTOS helped
to find it, so that you can fix it.

(Community is a large advantage for maintained code over
a dead binary version of OS.)

One of course will want to do final testing with "real" TOS,
but I think EmuTOS speed in booting and other advantages
more than compensate for any extra time spent for that.

Have you tried recent EmuTOS versions?


> 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.

[moved from earlier]
> 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 :)

I think I'll provide an extra script that invokes Hatari
with options that configure it more suitably for debugging.
It can be installed alongside Hatari.

Would "hatari-debug" be OK name for it?

Besides the "symbols resident" thing, I think by default it
should use "--trace os_base", and have some shorter option
(-e?) for "--debug-except".

It can output some debugger usage info (e.g. note about
"setopt -D"), and start a terminal for Hatari output if
user didn't start it from terminal.

Anything else?


	- Eero