| Re: [hatari-devel] Truncated PC address value with code running in TT-RAM? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 3/30/19 11:05 AM, Nicolas Pomarède wrote:
Le 29/03/2019 à 23:42, Eero Tamminen a écrit :
After some debugging I found out why disassembly didn't work with LILO.
It wasn't actually related to LILO, but code running in TT-RAM.
WinUAE core seems to now return 24-bit values for M68000_GetPC() macro,
although I've disabled 24-bit mode. With code running in TT-RAM,
M68000_GetPC() returns values pointing to ST-RAM addresses (which
contents happen to be zeroed).
Adding TT-RAM offset to return PC value, shows the correct disassembly:
disasm "pc + 0x1000000"
Even WinAUE core function for showing register values shows wrong
address for the next PC.
Because things still *run* correctly, and I'm pretty sure M68000_GetPC()
returned earlier correct 32-bit values for code running in TT-RAM,
When I added TT-RAM support to profiler in April 2015, it must have
worked correctly because I would certainly have noticed this kind
of issue.
(Hatari v1.9 was released 5 months later.)
it seems that CPU core PC register variable has changed into some kind
of memory segment offset value.
I will have a look ; which cpu were you using?
What one gets with "--machine falcon" i.e. 030.
Is it the same if you use internal disassembler or the external one ?
Yes.
But the problem isn't disassembler, it will disassemble fine whatever
I ask.
Problem is that M68000_GetPC() returns currently 24-bit value pointing
to ST-RAM address instead of correct 32-bit value pointing to TT-RAM,
so "pc" value from which disassembly starts (when user doesn't specify
an address), is incorrect.
M68000_GetPC() is used in really many places:
--------------------------
$ git grep -l M68000_GetPC
acia.c
bios.c
blitter.c
cpu/hatari-glue.c
debug/breakcond.c
debug/console.c
debug/debugInfo.c
debug/debugcpu.c
debug/evaluate.c
debug/history.c
debug/profilecpu.c
debug/vars.c
dmaSnd.c
fdc.c
floppy_ipf.c
gemdos.c
includes/m68000.h
ioMem.c
m68000.c
mfp.c
psg.c
spec512.c
stMemory.c
video.c
xbios.c
--------------------------
It's just an define/alias for WinUAE CPU m68k_getpc() function,
which is used in:
--------------------------
$ git grep -l m68k_getpc
cpu/cpu_prefetch.h
cpu/cpummu.c
cpu/cpummu.h
cpu/cpummu030.c
cpu/cpummu030.h
cpu/debug.c
cpu/fpp.c
cpu/gencpu.c
cpu/jit/compemu_fpp.c
cpu/jit/compemu_support.c
cpu/newcpu.c
cpu/newcpu.h
falcon/dsp.c
includes/m68000.h
m68000.c
--------------------------
WinUAE CPU core aliases M68K_GETPC to m68k_getpc(),
like M68000_GetPC() does:
#define M68K_GETPC m68k_getpc()
And because m68k_dumpstate(), called by m68k_dumpstate_file() has:
uaecptr pc = M68K_GETPC;
That explains why WinUAE CPU m68k_dumpstate_file() shows wrong
Next PC value:
-------------------------------------------------------
CPU=$6ae2, VBL=1118, FrameCycles=128, HBL=0, LineCycles=128, DSP=N/A
$00006ae2 : 0000 0000 ori.b #0,d0
> r
D0 0100180A D1 D0040000 D2 00000002 D3 00000002
D4 0003E5E2 D5 00000000 D6 00000000 D7 00000000
A0 00001804 A1 00040000 A2 03C2C650 A3 000011A0
A4 00006F5C A5 0000689E A6 03C2FF90 A7 03C2FEC4
USP 00000000 ISP 03C2FEC4 SFC 00000005 DFC 00000005
CACR 00001111 VBR 0036D858 CAAR 00000000 MSP 00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=2 STP=0
0: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
2: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
4: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
6: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
FPSR: 00000000 FPCR: 00000000 FPIAR: 00000000 N=0 Z=0 I=0 NAN=0
SRP: 8000000201001000 CRP: 0
TT0: 00000000 TT1: FE008543 TC: 82C07760
Prefetch 00006ae8 2f004879 (1) b682 (1) 6718 (1) 2f00 (1)
00006AE2 0000 0000 OR.B #$00,D0
Next PC: 00006ae6
-------------------------------------------------------
Like Next PC above, PC value gotten from M68000_GetPC() points
to wrong (zeroed) address area in ST-RAM:
-------------------------------------------------------
> d "pc-8"-"pc+2"
- 'pc-8' -> $6ada
- 'pc+2' -> $6ae4
$00006ada : 0000 0000 ori.b #0,d0
$00006ade : 0000 0000 ori.b #0,d0
$00006ae2 : 0000 0000 ori.b #0,d0
-------------------------------------------------------
Correct address is in TT-RAM:
-------------------------------------------------------
> d "0x1000000+pc-4"-"0x1000000+pc+2"
- '0x1000000+pc-4' -> $1006ade
- '0x1000000+pc+2' -> $1006ae4
$01006ade : 7403 moveq #3,d2
$01006ae0 : c480 and.l d0,d2
$01006ae2 : 7602 moveq #2,d3
-------------------------------------------------------
Register values correspond to what's done here, ($100180A & $3) = $2
i.e. the value shown in D2 register above.
- Eero