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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 17/11/2017 à 22:43, Eero Tamminen a écrit :

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

Yes, but my problem is "simple" : I want to code a program for STF/STE 
that will run on real HW. I don't have specific memory or OS needs, but 
it's just that in the past there where some difference between TOS and 
emutos about HW init (for example microwire init could be different).
I prefer to work the other way around : make sure the program works with 
real TOS and then in the end check it works with emutos too.

I like to code the oldschool way and in my case Emutos doesn't improve 
how fast I can code (if I want to boot faster, I just press alt+x, my PC 
is fast enough that booting will be done in less than 1 sec)


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

But why yet another script and some shorter options when it would be 
much simpler to make the above default in normal Hatari ?
If you agree that another script could be needed to make debugging 
easier in the scenario I reported, then the simplest would be to change 
the default to keep symbols resident.

I'm afraid people won't read doc or look for what such or such script is 
doing.

Nicolas