| Re: [hatari-devel] symbols not always loaded when entering debugger ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 11/15/2017 12:53 PM, Nicolas Pomarède wrote:
Le 15/11/2017 à 00:46, Eero Tamminen a écrit :
I mean to load the symbol when Hatari starts, even if we don't
enter the debugger at all.
If there's no program, how Hatari would know where to load
the symbols from, or to what address they should be relocated?
I mean that if you run "hatari test.prg", then symbols would be loaded
immediately if test.prg contains some symbols.
Not possible in practice inside the debugger itself. Program
basepage (= info needed for symbol relocation) is set up only
after Pexec() completes and GEMDOS HD emu catches only enter
into GEMDOS functions, not their exit.
You would need to set breakpoint either for Pexec() exit or
when there's valid basepage and PC points to TEXT section
start. However, that would affect emulation speed.
And if one doesn't enter debugger, what's the point of loading
symbols?
Symbols would be pre-loaded from a "clean" context, so in case we have
later a crash in the .prg that would prevent correctly loading symbols
from the .prg when entering debugger, then at least symbols would
already be there, even if the crashing .prg did a PTERM and exited.
Of course, you loose some memory/time at start by parsing symbols thtat
might not be used, but I would say that if a user compiles/assembles a
program with symbols then that migh mean that the user expect symbols to
be loaded later in a debugger.
Now, if the prgres allow to achieve the same result, it's not necessary > to load symbols at start.
I improved that a bit. Instead there's now a command:
symbols resident
Besides letting symbols persist after program exits, it
will automatically load them at program exit, if they
haven't been loaded yet.
(Improvement is that you can do it before program is run,
and you don't need to do it separately for every started
program instance.)
If you want that behavior to be the default, run Hatari
with the following option:
--parse debugger.ini
And put that command to the debugger.ini file (along
with any other debugger setup you like).
The symbols are there, after I press space and there's
address error:
--------------------------------------------------
....
--------------------------------------------------
What do you get with the same Hatari options?
If one continues from the address error, the program is terminated
and *then* its symbols aren't anymore valid and Hatari removes them.
The difference is that you used emutos for your test and that I used a
standard TOS (as my in STF/STE). And while emutos will not do a PTERM,
standard TOS does a PTERM :
Bus Error at address $ffff8a00, PC=$fc0ee0 addr_e3=fc0ee2 op_e3=4a68
GEMDOS 0x4B Pexec(0, "C:\TEST.PRG", [0]"", 0x0) at PC 0xFA002A
GEMDOS 0x3D Fopen("C:\TEST.PRG", read-only) at PC=0xFA002A
-> FD 64 (read-only -> read-only)
GEMDOS 0x4B Pexec(7, 0x0, 0xa542, 0x0) at PC 0xFA002A
GEMDOS 0x4B Pexec(5, 0x0, 0xa542, 0x0) at PC 0xFA002A
GEMDOS 0x3E Fclose(64) at PC 0xFA002A
Address Error at address $1001, PC=$128d4 addr_e3=128d6 op_e3=4e75
GEMDOS 0x4C Pterm(-1) at PC 0xFA002A
Even with normal TOS, Pterm() happens after address error, so you
still have symbols when the exception invokes the debugger???
If you want them to persist after program termination, use the new
"prgres" command while the program is still running:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/3bc9dc511e25
But I don't think that what people expect from a debugger : when a
program crashes, you expect infos to be persistant to be able to find
where was the crash. When coding in "higher" languages like C, you will
have more "security" provided by the standard libraries, but when you
want to code game/demo in pure asm, it's quite likely that at one point
you will have a pointer to the wrong memory region and your program will
corrupt memory and crashes.
In such case, symbols should be still there without requiring user's input.
If we want the debugger to be as efficient as possible for user, then it
should do most of these things by default.
If I run "hatari test.prg" and test.prg has some symbols and test.prg
crashes at one point and I'm dropped to the debugger, then by default I
think symbols should not be removed, even if program did a PTERM
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.
(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.)
(but
there could be a non default option "flush symbols on pterm" in case
someone really needs it).
As powerful the debugger/profiler might be, I read from users that they
often feel overwhelmed by the number of options when comparing to what
they used to do when they coded directly on ST (using devpac/monst for
example). All those options are powerful and useful, it's just that
simple tasks are not always as straightforward as they could be.
I experienced the same, I'm not sure the default behaviours are
targeting enough Atari devs to provide something similar to what they
used when coding on real STF/STE.
For the authentic experience, they could use the same (native)
debugger they used on their original STF/STE. :-)
- Eero