SEH-based exceptions enabled on win32

[Loesje]

SEH-based exceptions are made the default on the win32 target in fpc-trunk. For win64 they already where the default.

To build a compiler without SEH-based exceptions, the dDISABLE_WIN32_SEH option should be given. ie:

make all OPT='dDISABLE_WIN32_SEH'

Please report any regressions on the bug-tracker https://bugs.freepascal.org.

[marcov]

So when will this be merged to 3.2 ? :-)

[PascalDragon]

Not until this is fixed.

[Loesje]

Somewhere next week. Someone has to merge some C-block stuff.  Bought me some time. 

[Cyrax]

https://bugs.freepascal.org/view.php?id=34881 (Request debug info for SEH (finally/except) to prevent regression when win32 switches to SEH)

[PascalDragon]

Not a blocker anymore, considering that Martin has workarounds in place.

[Martin_fr]

Not a blocker anymore, considering that Martin has workarounds in place.

Only for Win64.  Still need to work on W32.

But the Dwarf SEH info is of limited help if at all.

1) It is unavailable in the default gdb based debugger. And even with FpDebug on the raise, things like cross debugging (ok *nix to win may be rare-ish) are still a task for gdb (server).

2) For FpDebug, as implemented in that patch, it is not useful either.
In SEH64 "finally" is a subroutine. In the actual function their is just a "call" asm statement. The call statement is used if there is no exception. If there is an exception, the call statement is not executed.
The dwarf info pointed to that call statement.
Ok, one could disassemble the call, to find the finally sub. But that is based on assumptions about implementation detail (there is exactly one call, and it goes directly to the address, that will be hit in case of exception)

I have not yet dug deep enough to come up with how to give useful debug info via dwarf.

So having to rely on implementation detail, other methods were found to deal with it.

[nanobit]

To build a compiler without SEH-based exceptions, the dDISABLE_WIN32_SEH option should be given.

At least, as long as debugging is not solved, there should be two fpc 3.2 release builds: SEH-based and sjlj-based.
It's better than long blockage of fpc 3.2. I have to admit, I don't know how long the blockage would be:)

[PascalDragon]

The debugging issue is not considered a blocker and we won't go the effort to build two releases.

[marcov]

Does using dwarf on Windows give correct tracebacks ?

I compiled a snapshot with -gw2 -godwarfsets  and it seems my tracebacks are useless. Should there be some -gl in addition?

[guest65109]

I don't know but why we have to do this? Why don't follow mingw64? If you download the mingw64 installer, you will see the 32 bit version only supports dwarf and sjlj, the 64 bit versions only supports sjlj and seh. SEH simply not available for 32 bit and dwarf simply not available for 64 bit. Plain and simple. If you develop for 32 bit, use dwarf. If you develop for 64 bit, seh is recommended.

[marcov]

I don't know but why we have to do this? Why don't follow mingw64?

Why would we? Why is what mingw64 does relevant? The system C compiler is MSVC.

If you download the mingw64 installer, you will see the 32 bit version only supports dwarf and sjlj, the 64 bit versions only supports sjlj and seh. SEH simply not available for 32 bit and dwarf simply not available for 64 bit. Plain and simple. If you develop for 32 bit, use dwarf. If you develop for 64 bit, seh is recommended.

You can't catch exceptions from MSVC dlls that way, and it really complicates exceptions in COM. It is all fun if you only live in your unix-emulation walled garden.

Moreover SEH is afaik more performant. SJLJ is a stopgap solution because SEH was patented for a long time, till a few years back.

That is probably also why mingw 32-bit doesn't, when the patent went off, they probably already focused mainly on mingw64

[guest65109]

Why would we? Why is what mingw64 does relevant? The system C compiler is MSVC.

I'm sorry. GCC is Linux focus and MinGW64 is a port of GCC to Windows. It's primarily developed for Unix. FPC on the other hand is Windows focus and has a port for Linux. It's primary developed for DOS. I used to ask why the GNU guys didn't recognize FPC as the official GNU Pascal compiler when GPC was no longer maintained even though FPC is also GPL and why the FPC developers didn't subject themselves under the GNU umbrella and becomes an official GNU project. Now I know why. I have confused between the two project's goal and primary audience.

p/s: don't confuse MinGW64 with Cygwin, Cygwin is an unix-emulator on Windows but MinGW64 compiles native binary without the need of any compatible layer. You shouldn't confuse between the MinGW64 compiler and the MSYS2 shell, too. MSYS2 is an Unix environment on Windows and the MinGW64 compiler should be used in conjunction with MSYS2 but it could run perfectly fine without MSYS2.

[Thaddy]

Why would we? Why is what mingw64 does relevant? The system C compiler is MSVC.

FPC on the other hand is Windows focus and has a port for Linux.

That may have been true in the very beginning 26 years ago but now that is complete nonsense for about 24 years.
The core developers are more than 50% unix oriented and some do not even use Windows. And the core team did not change so much 

[marcov]

Why would we? Why is what mingw64 does relevant? The system C compiler is MSVC.

I'm sorry. GCC is Linux focus and MinGW64 is a port of GCC to Windows.

Primarily meant to recompile POSIX (read:Unix) applications to Windows.  The workarounds and choices are primarily for that. It is less the compiler and more the build infrastructure (configure, make etc) and libraries that are hit by that.

FPC on the other hand is Windows focus and has a port for Linux.

The Linux port is actually older. Windows is more static in time though, so progresses better. Also the binutils were abandoned for a better performance and more flexible internal assembler and linker.

It's primary developed for DOS.

Dos is not really a factor after 2000-2003.

I used to ask why the GNU guys didn't recognize FPC as the official GNU Pascal compiler when GPC was no longer maintained even though FPC is also GPL and why the FPC developers didn't subject themselves under the GNU umbrella and becomes an official GNU project. Now I know why. I have confused between the two project's goal and primary audience.

And what brings you to that conclusion? Anyway there are more factors, some GPC members were also involved with FSF Europe, and FPC simply never asked to (why would it?).

Note that GPL is not enough for GNU, afaik you also need to file paperwork to transfer copyright to FSF. At least it used to be, maybe they are more flexible now.

p/s: don't confuse MinGW64 with Cygwin, Cygwin is an unix-emulator on Windows but MinGW64 compiles native binary without the need of any compatible layer. You shouldn't confuse between the MinGW64 compiler and the MSYS2 shell, too.

I know all that. But those are gradual differences, the base principle and intention remains the same.

MSYS2 is an Unix environment on Windows and the MinGW64 compiler should be used in conjunction with MSYS2 but it could run perfectly fine without MSYS2.

So, where do you get a working "make" and other tools then? The result is incomplete. Btw, many of the FPC buildtools are old mingw versions (circa 2005) before they started introducing MSYS.