[ruby-core:90127] Re: [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[Koichi Sasada <ko1@atdot.net>]

On my msys2 environment, it hits!

On my environemnt,

```
using
```

only this script hangs.


And I found these articles:

http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html

 > Following the thread’s advice, I was able to work around the issue by 
using the compiler’s built-in functions __builtin_setjmp and 
__builtin_longjmp instead of setjmp and longjmp. These seem to be 
alternative implementations included in GCC which don’t call msvcrt.dll. 
The downside is that the __builtin functions are GCC-specific and not 
technically user-facing. They could change in any release. But using the 
built-in functions did fix the crash bug, and now exception handling is 
working correctly in my project.

https://sourceforge.net/p/mingw-w64/bugs/406/
 > https://github.com/antoniovazquezblanco/nspire_emu uses setjmp and 
longjmp (emu.c) and crashes when used in a 64bit windows environment 
because setjmp sets the stack register value to 0x10. Using 
__builtin_setjump avoids the problem because the stack register doesn't 
get messed (doesn't seem to call setjmp3 function of the 
C:\Windows\SysWOW64\msvcrt.dll library).

I changed config.h to

```
#define RUBY_SETJMP(env) __builtin_setjmp((env))
#define RUBY_LONGJMP(env,val) __builtin_longjmp((env),val)
```

and this test passes!!!

I'm not sure it is correct way, but could you try it?

Thanks,
Koichi

On 2018/11/28 4:42, Greg.mpls@gmail.com wrote:
> Issue #15348 has been reported by MSP-Greg (Greg L).
> 
> ----------------------------------------
> Bug #15348: r66003 Support targetting TracePoint - MinGW
> https://bugs.ruby-lang.org/issues/15348
> 
> * Author: MSP-Greg (Greg L)
> * Status: Open
> * Priority: Normal
> * Assignee:
> * Target version:
> * ruby -v:
> * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
> ----------------------------------------
> This has caused failures in spec/ruby/core/main/using_spec.rb, specifically the first spec.
> 
> On Appveyor, trying several versions of both specs, the first one (`eval('using', TOPLEVEL_BINDING)`) fails, the second one (`eval('using "foo"', TOPLEVEL_BINDING)`) passes.
> 
> Locally (Windows 10), all versions of both specs have always passed using the same build (saved as an artifact) from Appveyor...
> 
> 
> 

-- 
// SASADA Koichi at atdot dot net