Hi Alexandre, I got bored and took a stab at doing proper SEH macros using some GCC extensions I found. These are rather rough, unfinished definitions, and they aren't tested at all but do they look OK? thanks -mike static void __wine_frame_cleanup( __WINE_FRAME *wineframe ) { __wine_pop_frame(&wineframe->frame); } #define __TRY \ { \ __label__ __frame_label; \ __WINE_FRAME __f __attribute__((cleanup(__wine_frame_cleanup))); \ if (0) { \ __frame_label: #define __EXCEPT(func) \ } \ else { \ __f.frame.Handler = __wine_exception_handler; \ __f.u.filter = (func); \ __wine_push_frame( &__f.frame ); \ goto __frame_label; \ } \ }
Mike Hearn <mh(a)codeweavers.com> writes:
Hi Alexandre,
I got bored and took a stab at doing proper SEH macros using some GCC extensions I found. These are rather rough, unfinished definitions, and they aren't tested at all but do they look OK?
They clearly won't work as is, but if your question is whether it's possible to use attribute((cleanup)), then yes you could probably use that to make the current macros more compatible. Obviously that would be only as an option for Winelib apps since it's not portable. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 2005-05-06 at 16:23 +0200, Alexandre Julliard wrote:
They clearly won't work as is, but if your question is whether it's possible to use attribute((cleanup)), then yes you could probably use that to make the current macros more compatible. Obviously that would be only as an option for Winelib apps since it's not portable.
Sure, that's what I was asking. I wanted to see if we could make break/continue/return work inside TRY macros, which this technique seems to give. As we already decided it'd need compiler support it's no big deal that it's not portable (between compilers). At least it probably works on an unmodified GCC. So now if somebody wants to go ahead and improve our SEH macros using this technique, please, be my guest ... thanks -mike
On Friday 06 May 2005 18:51, Mike Hearn wrote:
On Fri, 2005-05-06 at 16:23 +0200, Alexandre Julliard wrote:
They clearly won't work as is, but if your question is whether it's possible to use attribute((cleanup)), then yes you could probably use that to make the current macros more compatible. Obviously that would be only as an option for Winelib apps since it's not portable.
Sure, that's what I was asking. I wanted to see if we could make break/continue/return work inside TRY macros, which this technique seems to give. As we already decided it'd need compiler support it's no big deal that it's not portable (between compilers). At least it probably works on an unmodified GCC.
So now if somebody wants to go ahead and improve our SEH macros using this technique, please, be my guest ...
Mike, you wicked, evil man! I have exams to study for! BTW, hi everybody. No promises, but maybe in a few weeks, I will look at this. As for the portability issue, why not an autoconf test? Perhaps the answer is "because there are still people foolish enough to run distro's other than Gentoo." If so, then why not an autoconf test and a run-time test? -- gmt
On Mon, 09 May 2005 07:41:46 +0000, Gregory M. Turner wrote:
As for the portability issue, why not an autoconf test? Perhaps the answer is "because there are still people foolish enough to run distro's other than Gentoo." If so, then why not an autoconf test and a run-time test?
Hurrah! Well, this doesn't need any runtime code AFAICT, just GCC support. So a simple ifdef should be A-OK. thanks -mike
On Monday 09 May 2005 11:29, Mike Hearn wrote:
On Mon, 09 May 2005 07:41:46 +0000, Gregory M. Turner wrote:
As for the portability issue, why not an autoconf test? Perhaps the answer is "because there are still people foolish enough to run distro's other than Gentoo." If so, then why not an autoconf test and a run-time test?
Hurrah! Well, this doesn't need any runtime code AFAICT, just GCC support. So a simple ifdef should be A-OK.
Cool.... will be interesting to see how they did it. -- gmt
Why doesnt someone just implement the microsoft SEH keywords and extentions into GCC like it should be? Same with anything else microsoft that WINE or ReactOS needs (e.g. _declspec(thread) support)
"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote:
Why doesnt someone just implement the microsoft SEH keywords and extentions into GCC like it should be?
Because it's patented by Borland?
Same with anything else microsoft that WINE or ReactOS needs (e.g. _declspec(thread) support)
We can easily avoid to use it. -- Dmitry.
"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote:
Why doesnt someone just implement the microsoft SEH keywords and extentions into GCC like it should be?
Do you have any knowledge of GCC, to be able to do it, or help me do it?
Dmitry Timoshkov wrote:
Because it's patented by Borland?
Do you have any reference to the patent? It looks to me like it is easy to by-pass by using different key words and than the user can Just define them to the MS ones.
Same with anything else microsoft that WINE or ReactOS needs (e.g. _declspec(thread) support)
Most of them are implemented at least in MinGW. Or have parallels that can easily be #defined too. There is some work to do in porting the MinGW-PE stuff also for GCC-ELF, mainly dllexport/dllimport Free Life Boaz
On Monday 09 May 2005 10:00, Boaz Harrosh wrote:
"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote:
Why doesnt someone just implement the microsoft SEH keywords and extentions into GCC like it should be?
Do you have any knowledge of GCC, to be able to do it, or help me do it?
The code exists to do it, or used to, but there are technical and institutional barriers to inclusion in mainline gcc.
Dmitry Timoshkov wrote:
Because it's patented by Borland?
Do you have any reference to the patent? It looks to me like it is easy to by-pass by using different key words and than the user can Just define them to the MS ones.
US Patent #5,628,016, Kukol, May 6, 1997. And you can't patent a name, so changing names won't help. But you can patent wiping your ass after defecating. Which is basically what Borland has done here. -- gmt
Dmitry Timoshkov wrote:
Because it's patented by Borland?
Do you have any reference to the patent? It looks to me like it is easy to by-pass by using different key words and than the user can Just define them to the MS ones.
US Patent #5,628,016, Kukol, May 6, 1997. And you can't patent a name, so changing names won't help.
But you can patent wiping your ass after defecating. Which is basically what Borland has done here.
From this page: http://www.mega-tokyo.com/osfaq2/index.php/Doing%20a%20kernel%20in%20C++?ver... -----------snip http://www.codeproject.com/cpp/exceptionhandler.asp (explaining the stuff, but for VC++. Note that, on x86, VC++ and most other PC compilers use a stack-based unwinding and handling mechanism known as SEH, common to OS/2, Windows and Windows NT and described in detail in a famous MSJ article, http://www.microsoft.com/msj/0197/Exception/Exception.aspx GCC and most other UNIX compilers, instead, use the same table-based mechanism that is the rule on RISC architectures on x86 too. Also note that any use of stack-based SEH may or may not be covered by USPTO patent #5,628,016, held by Borland International, Inc. SEH on RISC architectures is table-based, thus unaffected by the patent) -----------snip The link to the patent is (without really reading all of it :) http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1... I wonder though: if stack-based SEH is patented by Borland, does it mean that "VC++ and most other PC compilers" pay to Borland? bye Fabi
On Mon, 09 May 2005 15:04:40 +0200, Fabian Cenedese wrote:
I wonder though: if stack-based SEH is patented by Borland, does it mean that "VC++ and most other PC compilers" pay to Borland?
The GNU EH ABI is table-based not stack based, I guess that's one reason why (it's also faster). thanks -mike
participants (7)
-
Alexandre Julliard -
Boaz Harrosh -
Dmitry Timoshkov -
Fabian Cenedese -
Gregory M. Turner -
Jonathan Wilson -
Mike Hearn