|Re: [hatari-devel] symbols not always loaded when entering debugger ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 13/11/2017 à 23:45, Eero Tamminen a écrit :
On 11/13/2017 04:10 PM, Nicolas Pomarède wrote:
Le 12/11/2017 à 22:29, Eero Tamminen a écrit :
I confirm that with your latest changes there's no more warning
"ignoring symbol xxxx with invalid offset" when symbol is the last of
Still, I see some warning if 2 symbols share the same address, I'm not
sure this is meaningful as this can be done on purpose in the source
See the attached .s and .prg for an example :
WARNING: symbols 'buf' & 'end_main' have the same 0x128ba address.
In the case where bss section is allocated just after the text
section, addresses will be the same.
Sure. However, normally most of the symbols come from libraries
user is linking, not from the code user has written himself.
I'm not sure of your statistic about this :) I mostly coded in asm on
68000 and all my symbols came from asm source, not external libraries,
so when a symbol is there it has a real meaning :)
For example, calling memcpy() instead of memmove() when src & dst
address ranges overlap, would be a bug. C-library itself can
alias the functions though, if it's memcpy() implementation is
safe for this. So, user could get confused when seeing memcpy()
symbol in disassembly, when he called memmove() in his own code.
That's why the warning is needed.
-> I added extra message about why user should be aware of
the symbol name & address duplicates.
then maybe the best of both cases would be to keep symbols from the
loaded prg (as they come from the user) and remove duplicates only when
it's a reference to an external library (don't know if that's possible
Also, you can test the case where symbols are not loaded after the
crash. run the attached prg and when screen goes "green", press
alt+pause to go to debugger and symbols will be loaded.
Now go back to emulation (press 'c') and press "space" to create a 3
bombs address error.
Debugger is called, but symbols are not loaded.
As symbols are already loaded, there's no point in debugger loading
them again for the same program, when debugger is re-entered.
>As Thorsten suggested,
this might because the prg is not running anymore from TOS point of
view, but still if you compare with "monst" for example, it would be
good to have symbols anyway from the prg that was running.
Maybe symbols could be loaded once at start, and not later when
entering debugger ?
They *are* loaded only once, automatically, when the debugger
is entered for the first time after starting given program.
I mean to load the symbol when Hatari starts, even if we don't enter the
debugger at all.
(Unless user has re-started the program, at which point debugger
does(?) the right thing and re-loads the symbols, in case program
changed, or it got located to different address.)
If symbols are loaded at start (which is fine), then why are there
removed after the exception error in the test program I sent ?
I think that once symbols are loaded, they should be kept until
explicitely flushed by the user, even if the corresponding program
crashed, else you loose the benefit of symbols if you can't inspect the
memory of the crashing program later.
Did you try the test.prg I sent, do you see why the symbols are not
there anymore after the 3 bombs I trigger ?