| Re: [hatari-devel] Support for loading GNU-style symbols from a.out executables |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 11/07/2017 02:05 AM, Thorsten Otto wrote:
On Montag, 6. November 2017 13:56:16 CET Thorsten Otto wrote:
Two more small patches that might be useful. The first uses the info from
readline or environment to determine how many symbols to display.
Nice!
Currently following commands:
- disasm
- memdump
- dspdisasm
- dspmemdump
- profile addresses
- dspprofile addresses
Use following parameters:
- ConfigureParams.Debugger.nDisasmLines
- ConfigureParams.Debugger.nMemdumpLines
to limit how many lines they output on each invocation
(on next invocation they continue from next address,
if user didn't specify start/end address).
I'm wondering whether pager similar to symbols command would be
nicer with them, and would you be interested to look into that?
I also changed the getchar() to fgets(), because otherwise, if you stop
the list, the next time that function is entered you will get the newline
from the previous run.
The second delays the duplicate symbol check to after sorting. The current
solution does it at part of the qsort() callback function, which results in
the same symbol to be reported several times, when it is compared several
times.
I don't think I've ever encountered the latter issue, and for some
reason I've never noticed the first issue. Anyway, the patches were
fine, so I pushed them (I removed the extra spaces at line ends).
Thanks!
There are some small problems remaining. Ie. it currently always will report
the linker generated symbols __edata and __bss_start, because they always will
have the same address. It also will report local names from distinct modules
as duplicates, because there is no distinction between local/global symbols.
And when using mintlib, it will also report some symbols that are deliberately
set at aliases there, like memcpy & memmove.
I don't think the aliases are really a problem. Hatari only matches
one of the symbols, so it's fine that it lists on loading what are
their aliases. That way there's less chance of confusion when user
e.g. sees memcpy() in debugger/profiler output instead of memmove(),
or other way round.
As to local symbols, in most cases, it could be better just to get
rid of them. They don't have proper names, and can be e.g. loop
labels, which cause some confusion when interpreting profiler
callgraphs.
- Eero
PS. I didn't have yet time to try your a.out patch, hopefully tomorrow.