Re: [Tinycc-devel] Windows x86_64 BUG, SIGSEV is not correctly handled by installed signal handler.

[Christian Jullien]

Michael,

 

For the context, I'm trying to make tcc a "Gold" Windows port of my OpenLisp ISLISP compiler, i.e. a Gold port runs the full test suite and introduces no performance regression (and I like tcc compiler so much that I'm considering tcc as main devel compiler).

For the recall, OpenLisp runs on > 150 different systems, compilers or processors. On Windows only cl and gcc are currently Gold ports.

 

Just on native Windows x64 (PE+), OpenLisp is used every day by:

 

·         GNU GCC 8.x (Mingw64)

·         LCC C Compiler (J. Navia version)

·         LLVM Clang 9.x

·         Microsoft C 19.0

·         Pelles C Compiler

·         Tiny C Compiler

 

In the past, on Windows, I also used Intel, OpenWatcom, DMC and a very old VisualAge

 

Signal code sample runs correctly on all of them excepted on "LCC" and "Tiny C"

 

The SIGSEGV is used to trap incorrect code users can enter in the Lisp REPL

 

? (catch 1 . 2)

** <program-error> : OpenLisp : machine-error : 11

? (quit)

 

Without correct signal handling, tcc port returns to system with no way to recover.

 

? (catch 1 . 2)

C:>

 

The nice consequence for tcc being a Gold port is that I’ll find more bugs thanks to my very huge test suite. It’s probably less interesting for maintainers :o))

 

The good point is that signal issue is probably the last error before tcc is promoted “Gold” on PE+, it is already Gold on PE

 

Christian             

 

-----Original Message-----
From: Michael Matz [mailto:address@hidden
Sent: Tuesday, April 09, 2019 15:08
To: address@hidden; address@hidden
Subject: Re: [Tinycc-devel] Windows x86_64 BUG, SIGSEV is not correctly handled by installed signal handler.

 

Hi,

 

On Tue, 9 Apr 2019, Christian Jullien wrote:

 

> 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.

 

So, up to here everything is as expected ...

 

> "Continue", this time, gives

> Unhandled exception at 0x0000000000401087 in signal.exe: 0xC0000005: Access

> violation writing location 0x0000000000000000

 

... but this should have been transformed into delivering a signal like in

32bit.  I know that signals are somewhat special on Windows and that it

supports only a subset of POSIX signals natively, but SEGV is among those

supported.  Does the example work when compiled by visual studio?  If so,

what's the difference that matters? :)

 

 

Ciao,

Michael.