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 Mittwoch, 8. November 2017 00:10:06 CET Eero Tamminen wrote:
> I'm wondering whether pager similar to symbols command would be
> nicer with them, and would you be interested to look into that?
I can do that if nobody else volunteers ;)
> I don't think I've ever encountered the latter issue
Might depend on how large your symbol tables usually are (when linking against
mintlib, there are lots of them), but the callback is called for every needed
comparison. If you would use a bubble-sort, that would be called several
hundred times for the same symbol.
> and for some reason I've never noticed the first issue
Thats normal behaviour. The terminal is in line-buffered mode at this time, so
getchar() does not return until you entered a full line, but will only eat the
first character ("q" in this case). Next time getchar is called, it will not
wait for input but return the newline instead, thus showing 2 pages instead of
1.
I'm not even sure wether it is the right thing to call getchar() or fgets()
there, when readline is in use. It might have same bad side effects, or
confuse the library.
>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
That should only be the case for compiler generated symbols, which are already
taken care of by ignoring ".L*". But you can still have the same static "x"
variable in 2 different modules, and it will appear with that name 2 times in
the output. Newer versions of gcc also sometimes create functions on their
own, like "myfunc.constprop", depending on optimizations.