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