| Re: [hatari-devel] Support for loading GNU-style symbols from a.out executables |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 11/08/2017 12:16 PM, Thorsten Otto wrote:
On Mittwoch, 8. November 2017 01:08:41 CET Thorsten Otto wrote:
I can do that if nobody else volunteers
done know ;)
I commited a modified version of it:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/8f362edccc7f
I also added the symbol support to the gst2ascii tool.
Great, thanks! (Didn't have yet time to try it out.)
To activate the new screen-size dependent display support, you have to change
the nDisasmLines and nMemdebugLines variables in already existing config files
to -1, which is now also written as default. I choosed -1, because zero was
already special-treated in the profiling commands.
Sounds good.
Maybe that should also be mentioned somewhere, at least in some changelog.
Note to myself: mention this in release-notes.txt.
What i noticed when adding the symbol support to the tool: it looks like the
gst symbols produced by gcc are always section-based, which means that all
data & bss addresses start at zero again. I'm not sure wether that is
intended, or a bug in the binutils,
It's correct.
The section address can be determined only when the program is loaded
(where in RAM the program ends, depends on OS memory situation), so
the address offsetting can be done only when you load the symbols
for the active program in the debugger.
Because most programs don't load into fixed address (like EmuTOS),
symbols are normally offsets to some section (some demos may load
themselves to fixed address though, but in the process they may
e.g. overwrite part of the OS accidentally).
> but although the tool tries to catch that case, it makes no attempt
> to change the value. That makes sorting the symbols by address rather
> useless,
Just filter/grep the addresses by type. Offsetting is done when
tool output is loaded to debugger.
> and would make it difficult for a user to find out the
> real address of a variable.
You can know that only after OS has loaded the program.
(Normally program loads to same address, if you haven't
changed steps you do from boot before loading the program,
and haven't change the RAM amount, type or TOS version.)
Also, the output from the a.out symbols (and also what is e.g. produced by the
map2sym.sh script from EmuTOS) is different, ie. the addresses of the data
segment are starting just after the text segment (for Emutos this is
irrelevant anyway, since there is no data segment, and the bss segment is
located in ram). I don't know wether that symbols are used at all by Hatari,
at least for profiling they won't be needed, but if they are, one or the other
of this functions should be changed to produce a consistent result.
Yes, there are some differences on whether symbols of different
type are offset to TEXT section start, or their own sections.
Linkers offsetting all symbols from beginning of TEXT section,
rely on OS putting all the sections to contiguous address ranges
in RAM. I don't know whether that's specified anywhere, or
would it be within spec if OS would put them into wildly different
addresses.
Debugger symbols command has defaults on what sections it uses
for offsets on given symbol types, but user can override it.
As to symbol type support, only breakpoints and disassembly
commands TAB-complete just TEXT/code symbol names, other
commands TAB-complete also other symbol types.
(Assuming I still remember this stuff correctly...)
- Eero