|Re: [hatari-devel] symbols not always loaded when entering debugger ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 11/14/2017 11:27 AM, Nicolas Pomarède wrote:
Le 13/11/2017 à 23:45, Eero Tamminen a écrit :
On 11/13/2017 04:10 PM, Nicolas Pomarède wrote:
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
No symbols are removed or ignored because of these warnings
(as you can see, when you list them). It's just a notice that
only one of the duplicates can be shown by Hatari when address
is matched to a name, or name to a address.
(Binary search returns just one index, not a range of them.)
I just noticed that your duplicate symbols actually have
different types. -> This commit removes your warning:
[...]>> >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.
If there's no program, how Hatari would know where to load
the symbols from, or to what address they should be relocated?
And if one doesn't enter debugger, what's the point of loading
(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 ?
The symbols are there, after I press space and there's
$ hatari --trace os_base --tos etos512k.img --debug-except
autostart,address -m test.prg
ARG = autostart program: test.prg
ARG = GEMDOS HD dir: testcase
Hatari v2.0.0, compiled on: Nov 13 2017, 00:42:11
CPU=68000, FPU=0, MMU=0, JIT=0. prefetch and cycle-exact 24-bit
GEMDOS 0x4B Pexec(0, "C:\TEST.PRG", "", 0x14b48) at PC 0xFA002A
GEMDOS 0x3D Fopen("C:\TEST.PRG", read-only) at PC=0xFA002A
-> FD 64 (read-only -> read-only)
GEMDOS 0x4B Pexec(7, 0x0, 0x14bd4, 0x14b48) at PC 0xFA002A
GEMDOS 0x3E Fclose(64) at PC 0xFA002A
You have entered debug mode. Type c to continue emulation, h for help.
Reading symbols from program
'/home/eero/work/hatari/build-gcc/testcase/test.prg' symbol table...
TOS executable, DRI / GST symbol table, reloc=0, program flags: PRIVATE
Trying to load symbol table at offset 0x4e...
WARNING: symbols 'buf' & 'end_main' have the same 0x16f5a address
-> Hatari profiles/dissassembly will show only one of the symbols for
Loaded 7 symbols from 'test.prg'.
CPU=$16f4c, VBL=1885, FrameCycles=112312, HBL=0, LineCycles=88, DSP=$0
$00016f4c : 66f8 bne.s $16f46
Returning to emulation...
<here I press the SPACE key>
Address error exception at 0x16f54!
CPU=$16f54, VBL=3475, FrameCycles=31900, HBL=142, LineCycles=92, DSP=$0
$00016f54 : 4e75 rts
CPU symbols sorted by name:
0x00016f46 T WaitSpace
0x00016f5a B buf
0x00017022 B buf_end
0x00016f40 T color
0x00016f4e T crash
0x00016f5a T end_main
0x00016f56 T old_sp
What do you get with the same Hatari options?
If one continues from the address error, the program is terminated
and *then* its symbols aren't anymore valid and Hatari removes them.
If you want them to persist after program termination, use the new
"prgres" command while the program is still running: