GCC 4.6 and newer miscompile SheepShaver JIT #21
Comments
I'm not sure 2. is possible, but I suppose you could try playing around One way to solve 3. is to check-in generated source files produced with Patches welcome! -Alexei On Sun, Mar 3, 2013 at 4:54 PM, Dave Vasilevsky notifications@github.comwrote:
|
|
Actually 1 is looking a lot harder than I thought. We don't actually want the Even if we detect the |
|
Did you try -mpush-args ? |
|
I got dyngen working with GCC 5.3.0 from MacPorts on OS X 10.11, arch i386: https://github.com/vasi/macemu/tree/gcc5 I basically just provided some extra arguments to DYNGEN_CC, and also strengthened our dyngen_barrier(). This is just a patch-up, not a general solution to all our future dyngen problems. I haven't yet tested with other compilers, versions of compilers, operating systems, or architectures. Any opinions? |
|
I've been using the following Ruby script under OS X to check for problems with the *-dyngen-ops.o files: #!/usr/bin/env ruby
def check_ret_at_end(lines)
return false if lines.count { |l| l =~ /\sret.?\b/ } != 1
lines.reverse.each do |line|
next if line =~ /\snop.?\b/
return line =~ /\sret.?\b/
end
end
def check_file(file)
IO.popen(['otool', '-tv', file]) do |io|
io.slice_before(/^\.?\w+:$/).each do |func|
next if func.first =~ /^\./
next if func.first =~ /impl_op_invoke/
next if func.last =~ /__TEXT/
if !check_ret_at_end(func) || !func.grep(/\spush.?\b/).empty?
puts func
end
end
end
end
ARGV.each { |f| check_file(f) } |
|
I just tried on Ubuntu Trusty, with the builtin GCC 4.8. Seems to work targeting i386, but not yet targeting amd64. |
|
In a few minutes of randomly trying things, I haven't figured out what's wrong with amd64. It would probably be easier if I could get mon working, but I'm not sure how. I'll look into it later. |
|
Seeing something similar on gcc-5.3.1-2.fc22.x86_64, with and without JIT, on x86_64. Got the following crash/trace. Sounds a little bit like this, though it's outside my realm of expertise: https://sourceware.org/ml/libc-alpha/2014-07/msg00020.html |
…stretch screen"
frsqrte updates fpscr
Dyngen requires that all op_* functions end in a 'ret' instruction on x86. But newer GCC will sometimes not put the ret there, instead using one or more jmp's.
We need to do one of the following:
The text was updated successfully, but these errors were encountered: