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:matz....@frakked.de] 
Sent: Tuesday, April 09, 2019 15:08
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 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.

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

Reply via email to