[hatari-devel] SIGSEGV error with MMU

Wed Feb 23 21:18:01 CET 2011

To complete my precedent mail, I would enjoy cleaning more the new code, 
if allowed ;)

JIT is absolutely not used for now. I don't even know if it compiles.

Regards

Laurent

Le 23/02/2011 21:12, Laurent Sallafranque a écrit :
> (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
>>
>>
>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel