Does it work if you replace ("flushw" : : : "%o7") with just ("flushw")? If it is, then it just has to be protected by #ifdef __GNUC__, i.e. the body of the function should look something like this (untested): void flush_sparc_registe...jurij (Jurij Smakov)
I've noticed that a failure to create a timer thread causes the following to appear in dmesg: [ 2047.656289] FAULT[miniruby:2299]: 32-bit process reports 64-bit fault address [16fdf6d9d] [ 2047.764409] TSTATE: 0000008011001600 TPC: 0...jurij (Jurij Smakov)
Attached is a patch for this problem, fixing the issue by moving the windows-flushing instruction into a separate function on sparc. It will still use flushw any sparcv9-capable machine irrespective of the OS. I've verified that it fixes...jurij (Jurij Smakov)
Ok, the story is probably more complicated than just this commit breaking it. I tried reverting r33357 in the latest SVN snapshot, and it still fails when configuring fiddle.jurij (Jurij Smakov)
While trying to build the Ruby SVN nightly snapshot I found that it fails while configuring fiddle: [...] configuring digest/sha2 configuring dl configuring dl/callback configuring dl/win32 Failed to configure dl/win32. It will ...jurij (Jurij Smakov)
Sorry, but this is not a proper fix. While it will fix the immediate problem for Debian, other systems will still be affected. Out of curiosity I tried building the latest svn snapshot (including this fix) on a freebsd/sparc64 system, an...jurij (Jurij Smakov)
My machine is UltraSparc III based, so it's a v9 and 64-bit. For historical reasons though Debian is using 64-bit kernel and 32-bit userspace: jurij@debian:~$ gcc -E -dM -xc /dev/null | grep -i -e sparc -e arch64 #define sparc 1 #de...jurij (Jurij Smakov)
I think we figured it out. The problem arises in cont_save_machine_stack() function, where the register windows are flushed using 'flushw' assembler instruction, and the machine stack is then saved by memcpy'ing it from cont->machine_sta...jurij (Jurij Smakov)
I looked at it some more (ruby1.9.1-1.9.3~preview1+svn33236 now), and tried to figure out what goes wrong by comparing the binaries compiled with -O0 and -O2. The call to ruby_longjmp does not look suspicious, I've verified that in both ...jurij (Jurij Smakov)