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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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?

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


Nicolas