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

[ Thread Index | Date Index | More Archives ]

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.

And if one doesn't enter debugger, what's the point of loading

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.

The symbols are there, after I press space and there's
address error:
$ hatari --trace os_base --tos etos512k.img --debug-except autostart,address -m test.prg
ARG = autostart program: test.prg
ARG = GEMDOS HD dir: testcase
Hatari v2.0.0, compiled on:  Nov 13 2017, 00:42:11
CPU=68000, FPU=0, MMU=0, JIT=0. prefetch and cycle-exact 24-bit
GEMDOS 0x4B Pexec(0, "C:\TEST.PRG", [0]"", 0x14b48) 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, 0x14bd4, 0x14b48) at PC 0xFA002A
GEMDOS 0x3E Fclose(64) at PC 0xFA002A
You have entered debug mode. Type c to continue emulation, h for help.
Reading symbols from program '/home/eero/work/hatari/build-gcc/testcase/test.prg' symbol table... TOS executable, DRI / GST symbol table, reloc=0, program flags: PRIVATE (0x0)
Trying to load symbol table at offset 0x4e...
WARNING: symbols 'buf' & 'end_main' have the same 0x16f5a address
-> Hatari profiles/dissassembly will show only one of the symbols for given address!
Loaded 7 symbols from 'test.prg'.

CPU=$16f4c, VBL=1885, FrameCycles=112312, HBL=0, LineCycles=88, DSP=$0
$00016f4c : 66f8                               bne.s     $16f46
 > c
Returning to emulation...
<here I press the SPACE key>
Address error exception at 0x16f54!

CPU=$16f54, VBL=3475, FrameCycles=31900, HBL=142, LineCycles=92, DSP=$0
$00016f54 : 4e75                               rts
 > symbols
CPU symbols sorted by name:
0x00016f46 T WaitSpace
0x00016f5a B buf
0x00017022 B buf_end
0x00016f40 T color
0x00016f4e T crash
0x00016f5a T end_main
0x00016f56 T old_sp

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

If you want them to persist after program termination, use the new
"prgres" command while the program is still running:

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


Mail converted by MHonArc 2.6.19+