Michael,

Here are few more inputs:

With 32bit version, VisualStudio debugger stops on

0x00401062 move byte ptr [eax],cl
Saying:
   Exception thrown at 0x00401062 in signal.exe: 0xC0000005: Access
violation writing location 0x00000000

"Continue", let me go to handler routine

With 64bit version, VisualStudio debugger stops on

0x0000000000401087 move byte ptr [rax],cl
Exception thrown at 0x0000000000401087 in signal.exe: 0xC0000005: Access
violation writing location 0x0000000000000000.

"Continue", this time, gives
Unhandled exception at 0x0000000000401087 in signal.exe: 0xC0000005: Access
violation writing location 0x0000000000000000

Other input, I go in handler if I call raise directly such as:

     signal(SIGSEGV, handler);
     raise(SIGSEGV);

This 64bit version also fails on Windows 10 VM machine and a native Windows
7 machine.


-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: Monday, April 08, 2019 20:35
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Windows x86_64 BUG, SIGSEV is not correctly
handled by installed signal handler.

Hi,

On Mon, 8 Apr 2019, Christian Jullien wrote:

> Hum!?
> My machine is a quite old Core i7 processor which has not all modern
> instructions (like AVX2).
> Could it be related to a generated instruction which does not exist on my
> processor.

No, TCC doesn't generate AVX (or AVX2) instructions by itself, so it's 
something else.  When I initially saw your mail I thought that maybe the 
calling convention for signal handlers is different from normal functions 
on win64 (which would have surprised me) but my experiment with wine 
wouldn't have worked if that were the reason :-/

> Pelle's C latest C compiler has a similar issue. Without specific 
> option, it sometimes generates AVX2 instructions which makes my machine 
> to hand.
> 
> M2c.
> 
> I'll try to debug this further...

Appreciated.


Ciao,
Michael.


> 
> C
> 
> -----Original Message-----
> From: Tinycc-devel
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of Michael Matz
> Sent: Monday, April 08, 2019 19:43
> To: jull...@eligis.com; tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Windows x86_64 BUG, SIGSEV is not correctly
> handled by installed signal handler.
> 
> Hello,
> 
> On Mon, 8 Apr 2019, Christian Jullien wrote:
> 
> > c:\tmp>tcc -m64 signal.c && signal
> > 
> > Waiting for SIGSEGV  <<= program terminates after this print!!
> 
> Works for me under wine64:
> 
> % ./x86_64-win32-tcc -m64 -B. -Iwin32/include -L. signal.c -Lwin32/lib
> % file signal.exe
> signal.exe: PE32+ executable (console) x86-64 (stripped to external PDB), 
> for MS Windows
> 
> (so it's really x86_64), and then:
> 
> % wine signal.exe
> Waiting for SIGSEGV
> Got signal 11!! Want to exit? [y/n] y
> Exiting from handler...
> 
> (answering 'n' works as expected too).
> 
> So I can't reproduce (with a quite different environment though).  As 
> you're probably using the same headers as me (the ones delivered with 
> tinycc) it would seem that the differences can't be coming from there, so
> the difference is coming from the runtime environment from Windows proper.

> I can't really speculate what that might be and how to amend TCC to care 
> for this; the code generation in principle works as demonstrated above, 
> some detail is missing :-/
> 
> 
> Ciao,
> Michael.
> 
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 
> 
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Reply via email to