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.




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