[hatari-devel] SIGSEGV error with MMU

[Laurent Sallafranque]

(gdb) p regs
$1 = {regs = {47, 65535, 0, 0, 65535, 14680064, 0, 0, 14680064, 2368, 0,
14683474, 14683140, 512, 0, 34924}, pc = 14685088, pc_p = 0x0,
pc_oldp = 0x0, irc = 65535, ir = 0, spcflags = 0, usp = 0, isp = 0, msp 
= 0,
sr = 9984, t1 = 0 '\000', t0 = 0 '\000', s = 1 '\001', m = 0 '\000',
x = 0 '\000', stopped = 0 '\000', intmask = 7, ipl = 0, ipl_pin = 0,
vbr = 0, sfc = 0, dfc = 0, fp = {0, 0, 0, 0, 0, 0, 0, 0}, fp_result = 1,
fpcr = 0, fpsr = 0, fpiar = 0, fpsr_highbyte = 0, cacr = 0, caar = 0,
itt0 = 0, itt1 = 0, dtt0 = 0, dtt1 = 0, tcr = 0, mmusr = 0, urp = 0,
srp = 0, buscr = 0, mmu_fslw = 0, mmu_fault_addr = 0, mmu_ssw = 0,
wb3_data = 0, wb3_status = 0, mmu_enabled = 0, mmu_pagesize_8k = 0,
fault_pc = 14681008, pcr = 0, address_space_mask = 0, panic = 0 '\000',
panic_pc = 0, panic_addr = 0, prefetch020data = {0, 0}, prefetch020addr = {
4294967295, 4294967295}, ce020memcycles = 0}


(gdb) p STRam
$2 = 
"`.\004\004\000\340\000\060\000\340\071\214\000\340\071\214\000\340\071\214\000\340\rR\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\224\352\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\rR\000\340\f\232\000\340\rR\000\340\f\260\000\340\rR\000\340\rR\000\340\rR\000\340\071\214\000\340\071\214\000\340\rR\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\r|\000\340\rv\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214\000\340\071\214", 
'\000' <se 
r\377\377\377\377\377������\000\000\000\377\377\377\377\377�������������������������

Hope this helps.


PS. I started reading cpu/memory.[ch]&  newcpu.h, but got confused with
the large amount of functions, struct members[1] and functions that aren't
used anywhere.  Is WinAUE code missing large pieces?


 From now, I've just tried to change as little as possible the original 
code, but removing only what avoid compilation.
Of course, we'll have to choose one day if we fork the original code and 
adapt it to our needs (that's what was done with previous old_core). In 
this case, it would be hardeer to diff WinUae's changes into our code. 
(but I'm not sure that WinUae will change a lot now).

If you're OK to use code cleaned, I can remove unused code, Amiga 
specific only code, ...
But maybe we'll need this code :
- for ST/STe emulation (run_P1 mode)
- for cycle exact
- for MMU,
- for ...

Regards

Laurent


Le 23/02/2011 20:55, Eero Tamminen a écrit :
> Hi,
>
> On keskiviikko 23 helmikuu 2011, Laurent Sallafranque wrote:
>> I've tested quickly the mmu code.
>>
>> I start with my usual 68030 CPU, no MMU.
>>
>> Then, I press "F12" and change the following parameters :
>> CPU = 68040, activate MMU
>>
>> Then I reset Hatari.
>>
>> I get a SIGSEGV error when hatari reset (look at the gdb trace) :
>>
>> Exception 2 (0) at e02ce2 ->  e02ce6!
>> Building CPU, 46224 opcodes (4 1 1)
>> CPU=68040, FPU=68040, MMU=1, JIT=0.
>> MMU: enabled=0 page8k=0
>> MMU: enabled=0 page8k=0
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000004f4e40 in get_iword () at
>> /home/laurent/Atari/hatari/src/cpu/newcpu.h:326
>> 326    {
>> (gdb) bt
>> #0  0x00000000004f4e40 in get_iword () at
>> /home/laurent/Atari/hatari/src/cpu/newcpu.h:326
>> #1  next_iword () at /home/laurent/Atari/hatari/src/cpu/newcpu.h:327
>> #2  0x00000000006fe8d4 in op_11b0_31_ff (opcode=5040) at
>> /home/laurent/Atari/hatari/build/src/cpu/cpuemu_31.c:7548
> ...
>
> static inline uae_u16 do_get_mem_word(void *a)
> {
>          return SDL_SwapBE16(*(uae_u16 *)a);
> }
> ...
> STATIC_INLINE uae_u32 get_iword (int o)
> {
>          return do_get_mem_word((uae_u16 *)((regs).pc_p + (o)));
> }
> ...
> STATIC_INLINE uae_u32 next_iword (void)
> {
>          uae_u32 r = get_iword (0);
>          m68k_incpc (2);
>          return r;
> }
>
>
> I.e. Hatari segfaulted when trying to byte-swap word at "regs.pc_p" address.
>
>
>> If anybody's got an idea of where the problem can come from, I'd be
>> happy to get some help.
> What gdb shows for "print regs" and "print STRam" after the crash?
>
> I.e. is regs.pc_p pointing even close to STRam array containing the emulated
> RAM?
>
>
>> I continue to search.
> Maybe the ST RAM memory accessor functions (in cpu/memory.c) aren't properly
> set up for MMU access?
>
>
> 	- Eero
>
> PS. I started reading cpu/memory.[ch]&  newcpu.h, but got confused with
> the large amount of functions, struct members[1] and functions that aren't
> used anywhere.  Is WinAUE code missing large pieces?
>
> [1] Try e.g.:
> 	grep -e baseaddr -e xlateaddr $(find -type f)
>
> Then I looked into JIT stuff, and uurgh...  That I definitely don't want to
> debug. :-)
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>