Re: [hatari-devel] Is it me or the symbols prg option is broken ?

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


> Does symbol loading work now? Le 12/06/2014 23:44, Eero Tamminen a écrit :


Yes it works again. Great job Eero.

What is fun is that now, I don't have to enter "symbols prg", when I break the program, hatari debugger immediatly loads the symbol table by itself.

Laurent


Hi,

On torstai 12 kesäkuu 2014, Laurent Sallafranque wrote:
Here is what I get :
  > symbols prg

Reading symbols from program
'/media/Win_NTFS/Jeux/Atari/DiskDur.FAL/Thadoss/RACER/RACER/RACER.PRG'
symbol table...
0x7 program flags, reloc=0, TOS executable, DRI / GST symbol table.
Trying to load symbol table at offset 0x8cee0...
WARNING: ignoring symbol 'DTA' of B type in slot 1 with invalid offset
0x183b40 (>= 0xf6cab).
WARNING: ignoring symbol 'MAXY' of D type in slot 6 with invalid offset
0x104114 (>= 0xe8e4b).
ERROR: too many invalid offsets, skipping rest of symbols!
Hm.  Devpac could be using TEXT-relative symbol offsets in its
symbol table.  Whereas e.g. GCC uses offsets that are relative to
the section where those symbols are, and so do some other things
(for which I fixed Hatari a while ago).

I added code to Hatari to try to load the DATA & BSS symbols
as TEXT relative if loading them as relative to their own
section fails (i.e. offsets would be outside of that section).

Does symbol loading work now?

If not, please provide Hatari "info basepage" output for your
program and Atari "nm" tool ouput for your binary symbol table.


	- Eero

PS. If somebody knows a flag in program header or DRI symbols
which tells to what the offsets are supposed to be relative to,
I would appreciate it.

ERROR: reading symbols from
'/media/Win_NTFS/Jeux/Atari/DiskDur.FAL/Thadoss/RACER/RACER/RACER.PRG'
failed!
'symbols' - load CPU symbols & their addresses
Usage:  symbols <filename|prg|addr|name|free> [<T offset> [<D offset> <B
offset>]]
      Loads symbol names and their addresses from the given file.
      If there were previously loaded symbols, they're replaced.

      Giving 'prg' instead of a file name, loads DRI/GST symbol table
      from the last program executed through the GEMDOS HD emulation.

      Giving either 'name' or 'addr' instead of a file name, will
      list the currently loaded symbols.  Giving 'free' will remove
      the loaded symbols.

      If one base address/offset is given, its added to all addresses.
      If three offsets are given (and non-zero), they're applied to
      text (T), data (D) and BSS (B) symbols.  Given offsets are used
      only when loading ASCII symbol files.


Laurent

Le 12/06/2014 20:24, Eero Tamminen a écrit :
Hi,

On torstai 12 kesäkuu 2014, Laurent Sallafranque wrote:
I compile Racer with the following options as I always did before:

opt    p=68030/68882,NOCASE,D+,X+

Then, I run Racer and break it in the main menu, but I get the
following

error message:
   > symbols prg

ERROR: no program loaded (through GEMDOS HD emu)!
Because autoloading of the symbols failed, Hatari removed information
about the program path from debug symbol code.  That's why you get
this strange error on following "symbols prg" commands.  I commited an
improvement which allows you seeing the errors again.

What error you get from symbols autoloading?

	- Eero
	
Laurent

Le 11/06/2014 23:09, Eero Tamminen a écrit :
Hi,

On keskiviikko 11 kesäkuu 2014, Laurent Sallafranque wrote:
I can't use symbols prg with the latest release.
What this means?

Is it me or something is broken here ?
Nowadays Hatari nowadays loads symbols automatically if program has
them.

Note that:

* with GCC you need to ask linker to generate old style (DRI)
symbols.

     More detailed a.out format symbols you need to output with nm and
     read as separate ASCII symbols file.

* if you're using VBCC, make sure that you use a version with fixed
linker.

     Older VBCC linker used broken data/bss symbol offsets.  For those
     you need to use gst2ascii program and load symbols as ASCII.
	
	- Eero






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