Re: [hatari-devel] Hatari Debugger Symbols

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 12/11/19 8:09 AM, Markus Fröschle wrote:
> Am Dienstag, den 10.12.2019, 21:30 +0200 schrieb Eero Tamminen:
> > Hatari config file [Debugger] section [1]
> > "bSymbolsResident" option controls whether
> > (autoloaded) symbols will be removed when program
> > exits.
> >
> > You can also load symbols at any point with the "symbols" command,
> > either from separate (ASCII)
> > symbols file, or from a program binary that
> > includes a symbol table.  Manual gives several
> > examples on different ways to do that.
>
> Thank you, Eero. This is what I tried before, but can't get to work. I
> probably need to be more specific: if I try to load the symbols from
> the executable at any arbitrary point, I get:
>
> Reading symbols from program 'auto/fvdi_gnu.prg' symbol table...
> GCC/MiNT executable, a.out symbol table, reloc=0, program flags:
> FASTLOAD TTRAMLOAD TTRAMMEM SUPER (0x27)
> ERROR: no valid program basepage!
>
> Which is reasonable as Hatari obviously needs a valid basepage to
> retrieve decipher relocation info.
>
> When I do this after the resident program loaded but not yet executed
> its Ptermres() call, the symbols are there, but vanish after next
> Pexec() call:
>
> >   cont
> Returning to emulation...Program launch, removing previous program
> symbols.
>
> It doesn't seem to make a difference whether I set the bSymbolsResident
> or not.

Currently that only disables automatic unloading
for symbols at program exit.


> If I try this later (after fvdi did its Ptermres() call), I get this:
>
> symbols auto/fvdi_gnu.prg
> WARNING: given program doesn't match last program executed by GEMDOS HD
> emulation:
> 	/home/mfro/Dokumente/Development/atari/fvdi_test/bench/bench.ap
> p
> Reading symbols from program 'auto/fvdi_gnu.prg' symbol table...
> GCC/MiNT executable, a.out symbol table, reloc=0, program flags:
> FASTLOAD TTRAMLOAD TTRAMMEM SUPER (0x27)
> ERROR: given program TEXT section size differs from one in RAM!
> ERROR: reading symbols from 'auto/fvdi_gnu.prg' failed!
>
> Which is reasonable as well, as I loaded another program in between and
> Hatari probably registered another basepage address.
>
> The setting of bSymbolsResident (isn't that the same thing as the
> 'symbols resident' command from within the debugger?) does not change
> anything - it appears to make Hatari retain symbols until next program
> load only?

Yes.  I could change the "resident" option to
disable automatic program symbols loading &
unloading (with GEMDOS HD) completely.

What the others think about this?


> It appears I'd need a 'symbols' command that allows me to pass the
> basepage address of my resident program (and probably relaxed sizechecking) to make that work?

Right, with above change, I would also need to add
support for providing text / code / bss addresses
(like with ASCII symbols), also when reading
symbols from Atari program.


On 12/11/19 8:37 AM, Markus Fröschle wrote:
> Nevermind, I think I found a workaround.
>
> If I load my fVDI test program (the one that's supposed to trigger the
> fVDI bug) from floppy instead of from a GEMDOS emulated hard drive,
> Hatari appears to bypass auto symbol loading for that executable and
> retains the original fVDI symbols loaded previously.

I think symbol unloading still happens if you have
GEMDOS tracing enabled, and haven't enabled the
resident option.

Automatic symbol loading is possible only with
GEMDOS HD emulation though, as that's the only
way for Hatari to get access to the program's
symbols data.


	- Eero