Re: [hatari-devel] Hatari Debugger Symbols

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/