basilisk-devel

[B2-devel] More SheepShaver segfaults on modern Ubuntu

[Dave V. <va...@us...>]

I'm working on some patches for SheepShaver, but I'm having trouble
getting SS compiling and working on Linux. SS builds ok, but then
running it always segfaults, I've pasted a backtrace below.

This happens with both SDL and X builds, with or without the JIT. The
only way I've been able to get it working is to build with -O0, but
that's impossibly slow. Old builds of SS from emaculation seem to work
ok. So maybe it has something to do with newer versions of GCC? I'm on
Ubuntu 12.10 amd64, with uses GCC 4.7.2.

Has anybody managed to build and run SS on modern Linux?

-Dave


powerpc_cpu::execute_loadstore<op_template_nop<unsigned int>,
input_gpr_except<bit_field<11, 15>, 0>,
immediate_operand<bit_field<16, 31>, op_sign_extend_16_32>, false, 4,
false, false> (this=0x783ada70, opcode=<optimized out>)
    at ../kpx_cpu/src/cpu/ppc/ppc-execute.cpp:585
585			memory_helper<SZ, RX>::store(ea, operand_RS::get(this, opcode));
(gdb) bt
#0  powerpc_cpu::execute_loadstore<op_template_nop<unsigned int>,
input_gpr_except<bit_field<11, 15>, 0>,
immediate_operand<bit_field<16, 31>, op_sign_extend_16_32>, false, 4,
false, false> (this=0x783ada70, opcode=<optimized out>)
    at ../kpx_cpu/src/cpu/ppc/ppc-execute.cpp:585
#1  0x0000000078096eac in nv_mem_fun1_t<void, powerpc_cpu, unsigned
int>::operator() (
    this=0x101407d0, p=0x783ada70, x=2424504320) at
../kpx_cpu/include/nvmemfun.hpp:88
#2  0x0000000078096049 in powerpc_cpu::execute (this=0x783ada70,
entry=1085341696)
    at ../kpx_cpu/src/cpu/ppc/ppc-cpu.cpp:686
#3  0x00000000780a9160 in emul_ppc (entry=1085341696)
    at ../kpx_cpu/sheepshaver_glue.cpp:925
#4  0x000000007804f3da in jump_to_rom (entry=1085341696) at main_unix.cpp:1204
#5  0x000000007804f40b in emul_func (arg=0x0) at main_unix.cpp:1224
#6  0x000000007804f05a in main (argc=1, argv=0x7fffffffe178) at
main_unix.cpp:1045

Re: [B2-devel] More SheepShaver segfaults on modern Ubuntu

[Alexander v. G. IV <kal...@un...>]

On 03/03/2013 10:40 am, Dave Vasilevsky wrote:
> I'm working on some patches for SheepShaver, but I'm having trouble
> getting SS compiling and working on Linux. SS builds ok, but then
> running it always segfaults, I've pasted a backtrace below.
> 
> Has anybody managed to build and run SS on modern Linux?
> 

While I was working on my redesigned fork, I ran into a similar issue.

The largest problem I see is that the memory management needs 
completely
redesigned and cleaned up. After looking extensively at the memory 
code, it
seems like SheepShaver was originally designed to run on the Native 
BeOS
PowerPC system with 1:1 memory mappings. That doesn't work on non-x86
so a virtual memory layer was kind of hacked in.

I gave my fork the old college try and did a *lot* of cleanup. However
a lot of work still remains and i'm afraid my low level PowerPC memory
management knowlege isn't enough to fix the issues.

If anyone is looking for a project.. :)

https://github.com/kallisti5/sheepshear

The sources are a lot cleaner in SheepShear.
(i'm thinking of changing the name again.. too close to SheepShaver)

  -- Alex

Re: [B2-devel] More SheepShaver segfaults on modern Ubuntu

[Dave V. <va...@us...>]

On Sun, Mar 3, 2013 at 11:40 AM, Dave Vasilevsky
<va...@us...> wrote:
> So maybe it has something to do with newer versions of GCC?

My hunch was right! Compiling with GCC 4.5 and earlier works, but with
GCC 4.6 and later does not. I did some bisecting, and relevant
difference looks like it's in ppc-dyngen-ops.cpp's op_jump_next_A0().
For the last part of that function, GCC 4.5 generates:

	cmpq	(%rax), %rdx
	jne	.L756
.L755:
	jmp	*112(%rax)
.L756:
	.p2align 4,,7
	ret
	.cfi_endproc

While GCC 4.6 generates:

	cmpq	(%rax), %rdx
	je	.L755
.L756:
	ret
.L755:
	.p2align 4,,8
	jmp	*112(%rax)
	.cfi_endproc

It looks like this should have identical effects, but it apparently
makes a difference. Any ideas what's going on?

-Dave

Re: [B2-devel] More SheepShaver segfaults on modern Ubuntu

[Dave V. <va...@us...>]

On Sun, Mar 3, 2013 at 1:54 PM, Dave Vasilevsky
<va...@us...> wrote:
> It looks like this should have identical effects, but it apparently
> makes a difference. Any ideas what's going on?

Ok, so it turns out that the difference is that dyngen looks for a
'ret' instruction to determine where the function ends. If the
branches are arranged so that the 'ret' isn't actually at the end, it
cuts the op short.

Unfortunately, I can't find any way to force GCC to place the ret at
the end of the function. Darn. I've filed an issue at github:
https://github.com/cebix/macemu/issues/21

-Dave

Re: [B2-devel] More SheepShaver segfaults on modern Ubuntu

[<bas...@sp...>]

Hi,

I think I had this problem on freebsd where I built gcc and it did not use 
typial options, try -mpush-args I am sorry I can't find that build anymore 
here, it might have been some other option too though like -fcaller-saves 
or -fno-defer-pop. I think it was under the 'Intel 386' sectoin in the gcc 
man page.

Good luck!
mzs