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

[ Thread Index | Date Index | More Archives ]

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.


Mail converted by MHonArc 2.6.19+