On 2012-07-25 22:39, Rainer Schuetze wrote:

> What is the state of the missing exception handling for Windows?

I just read an old post on the Clang mailing list, it's not looking good. It seems Microsoft (or someone else) has a patent on SEH, which basically means: never gonna happen. An alternative could be setjmp/longjmp. On 64bit it looks a bit better, where the correct way seems to be to use the Win64 exception ABI.

http://clang-developers.42468.n3.nabble.com/LLVM-Clang-and-setjmp-longjmp-exception-handling-on-MinGW-td3407322.html

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

-- 
/Jacob Carlborg

On 25.07.2012 22:39, Rainer Schuetze wrote:
>
>
> On 25.07.2012 06:28, huynh van sen wrote:
>> Please build LDC2 for windowXP with visual studio 2010
>> I try compling on windows XP 32 bit .But I get Error
>> Please Help me !
>>
>> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be in
>> segment
> ....
>> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
>> unmatched
>> block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>>
>>
>> "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
>> "C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
>> (Link target) ->
>>    LINK : fatal error LNK1104: cannot open file 'Program.lib'
>> [C:\ldcenv\build-l
>> dc2\ldmd2.vcxproj]
>>
>>      30 Warning(s)
>>      12 Error(s)
>>
>> Time Elapsed 00:00:20.18
>>
>> C:\ldcenv\build-ldc2>
>
> I have not tried to build LDC myself, but my guess is that there is
> something wrong with the build step for the assembly file ldfpu.asm. It
> seems the VS projects are generated from CMake, so it might not be setup
> correctly.
>
> For x64 builds, the command line in dmd_msc.vcproj is "ml64 -c -Zi
> "-Fl$(IntDir)\$(InputName).lst" "-Fo$(IntDir)\$(InputName).obj"
> "$(InputPath)".
> For win32 builds, ldfpu.asm should be excluded from the build, inline
> assembly is used instead in longdouble.c.
>
> BTW: are there instructions how to build LDC2 on Windows? What is the
> state of the missing exception handling for Windows?

Hi!

Thanks for the hint. I try to correct the build file generation. Because of missing SEH support (protected by patents :-( ), I only work on the x64 version of LDC.

Build instructions are here:
https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC

Regards
Kai

Hi huynh van sen!

This is fixed now. Please try again.

Regards
Kai

On 25.07.2012 06:28, huynh van sen wrote:
> Please build LDC2 for windowXP with visual studio 2010
> I try compling on windows XP 32 bit .But I get Error
> Please Help me !
>
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be in
> segment
>   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: must be in
> segment
>   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: must be in
> segment
>   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: must be in
> segment
>   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: must be in
> segment
>   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
> unmatched bl
> ock nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
> Done Building Project "C:\ldcenv\build-ldc2\LDCShared.vcxproj" (default
> targets
>
>
>
> "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
> "C:\ldcenv\build-ldc2\LDCShared.vcxproj" (default target) (2) ->
> (CustomBuild target) ->
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(23): error A2013: .MODEL
> must prec
> ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(25): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(27): error A2013: .MODEL
> must prec
> ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(31): error A2034: must be
> in segme
> nt block : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(32): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: must be
> in segme
> nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
> unmatched
> block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
>
>
> "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
> "C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
> (Link target) ->
>    LINK : fatal error LNK1104: cannot open file 'Program.lib'
> [C:\ldcenv\build-l
> dc2\ldmd2.vcxproj]
>
>      30 Warning(s)
>      12 Error(s)
>
> Time Elapsed 00:00:20.18
>
> C:\ldcenv\build-ldc2>

On 26/07/12 09:05, Jacob Carlborg wrote:
> On 2012-07-25 22:39, Rainer Schuetze wrote:
>
>> What is the state of the missing exception handling for Windows?
>
> I just read an old post on the Clang mailing list, it's not looking
> good. It seems Microsoft (or someone else) has a patent on SEH,

I've heard this, but does anyone know what patent is being referred to? Several times I've heard mention of an old one by Borland, which Microsoft bought. The Borland patent is not a patent on SEH, it's basically a patent on using a thunk. I suspect it is extremely unlikely to be a valid patent, for sure there is prior art. And the only reason for implementing it with a thunk anyway, is as a workaround for the broken thread-local support in Windows prior to Vista.

It's not difficult to implement SEH without violating that patent (which is due to expire soon anyway). Is there some other patent that people are referring to?


which
> basically means: never gonna happen. An alternative could be
> setjmp/longjmp. On 64bit it looks a bit better, where the correct way
> seems to be to use the Win64 exception ABI.

Win64 SEH is scarcely any different to Win32 SEH, it's just better documented. You can do the same thing on Win32.


> http://clang-developers.42468.n3.nabble.com/LLVM-Clang-and-setjmp-longjmp-exception-handling-on-MinGW-td3407322.html
>
>
> http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

The situation makes no sense to me.

On Tuesday, 31 July 2012 at 11:21:21 UTC, Don Clugston wrote:
> Win64 SEH is scarcely any different to Win32 SEH, it's just better documented. You can do the same thing on Win32.

Unless I'm mistaken, SEH on Win64 is quite a lot different to Win32, as it is based on tables, rather than keeping FS:[0] up to date in the function pro-/epilogues.

David

On 2012-07-31 13:21, Don Clugston wrote:

> I've heard this, but does anyone know what patent is being referred to?
> Several times I've heard mention of an old one by Borland, which
> Microsoft bought. The Borland patent is not a patent on SEH, it's
> basically a patent on using a thunk. I suspect it is extremely unlikely
> to be a valid patent, for sure there is prior art. And the only reason
> for implementing it with a thunk anyway, is as a workaround for the
> broken thread-local support in Windows prior to Vista.

I think it's this patent:

http://www.google.com/patents/about?id=21MgAAAAEBAJ&dq=5,628,016

Inventor: Peter Kukol
Original Assignee: Borland International, Inc.
Primary Examiner: Peter J. Corcoran, III
Current U.S. Classification: 717/140; 717/114
International Classification: G06F 945

> It's not difficult to implement SEH without violating that patent (which
> is due to expire soon anyway). Is there some other patent that people
> are referring to?

It doesn't matter. The Clang/LLVM developers won't accept an implementation that has any chance of being covered by a patent.

-- 
/Jacob Carlborg

Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception handling (and quite interesting, I'd say).

On 2012-08-04 17:20, Kagamin wrote:
> Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception
> handling (and quite interesting, I'd say).

This post recently appeared on the Clang mailing list:

"Hi,

I have just been made aware that GCC 4.7.2 and later will use SEH by default on Win64:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html

I would like to inquire as to possibility of this being implemented in Clang/LLVM. As this type of exception handling is much closer to the classic Dwarf model currently used, I hope it won't be too difficult to implement this in Clang? Remember that Win64 EH is broken right now, so any improvement is the right improvement ;-)

For 32-bit dw2 eh already works well, and in light of the misty Borland patents will probably remain the only option for a while.

Thanks!

Ruben

PS: please also reply to my email address, as I'm not subscribed to cfe-dev"


-- 
/Jacob Carlborg

On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg wrote:
> On 2012-08-04 17:20, Kagamin wrote:
>> Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception
>> handling (and quite interesting, I'd say).
>
> This post recently appeared on the Clang mailing list:
>
> "Hi,
>
> I have just been made aware that GCC 4.7.2 and later will use SEH by default on Win64:
> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html
>
> I would like to inquire as to possibility of this being implemented in Clang/LLVM. As this type of exception handling is much closer to the classic Dwarf model currently used, I hope it won't be too difficult to implement this in Clang? Remember that Win64 EH is broken right now, so any improvement is the right improvement ;-)
>
> For 32-bit dw2 eh already works well, and in light of the misty Borland patents will probably remain the only option for a while.
>
> Thanks!
>
> Ruben
>
> PS: please also reply to my email address, as I'm not subscribed to cfe-dev"

Charles Davis did a lot of work on Win64 SEH support in LLVM,
check commits r131652-r132880.

It's not finished yet. All the stuff for assembly code that uses
Win64 EH is done, but not the code-gen-side stuff (cf.
Win64Exception class in CodeGen). I was about to finish it, but
then real life happened :). This would have allowed us to use
DW2-style EH on Win64, but it still would have been problematic
for VC++ EH.

Kai Tietz was interested in finishing it, so I emailed him what I
have. I assume he's been working on it--he recently submitted a
patch to fix the permissions on .pdata/.xdata sections that I got
wrong :). I've CC'd him as well so we can see what he has for us.

Chip

It sounds like this should be targetable from ldc now.

On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:
> On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg wrote:
>> On 2012-08-04 17:20, Kagamin wrote:
>>> Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception
>>> handling (and quite interesting, I'd say).
>>
>> This post recently appeared on the Clang mailing list:
>>
>> "Hi,
>>
>> I have just been made aware that GCC 4.7.2 and later will use SEH by default on Win64:
>> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html
>>
>> I would like to inquire as to possibility of this being implemented in Clang/LLVM. As this type of exception handling is much closer to the classic Dwarf model currently used, I hope it won't be too difficult to implement this in Clang? Remember that Win64 EH is broken right now, so any improvement is the right improvement ;-)
>>
>> For 32-bit dw2 eh already works well, and in light of the misty Borland patents will probably remain the only option for a while.
>>
>> Thanks!
>>
>> Ruben
>>
>> PS: please also reply to my email address, as I'm not subscribed to cfe-dev"
>
> Charles Davis did a lot of work on Win64 SEH support in LLVM,
> check commits r131652-r132880.
>
> It's not finished yet. All the stuff for assembly code that uses
> Win64 EH is done, but not the code-gen-side stuff (cf.
> Win64Exception class in CodeGen). I was about to finish it, but
> then real life happened :). This would have allowed us to use
> DW2-style EH on Win64, but it still would have been problematic
> for VC++ EH.
>
> Kai Tietz was interested in finishing it, so I emailed him what I
> have. I assume he's been working on it--he recently submitted a
> patch to fix the permissions on .pdata/.xdata sections that I got
> wrong :). I've CC'd him as well so we can see what he has for us.
>
> Chip
>
> It sounds like this should be targetable from ldc now.

http://www.nynaeve.net/?p=113