Hello everyone,
I would like to know what the proper way is to write an exception filter function for WINE code. Most of the WINE exception filtering seems to be done with the __EXCEPT_PAGE_FAULT macro, for whatever reason. In all other places I see the macro __EXCEPT with a filter function of this prototype
LONG WINAPI filter(EXCEPTION_POINTERS *);
However, I have the need to implement a filter function that takes additional formal parameters such as the values of local parameters of the function where the SEH frame resides. Alternatively, I would like to do something like the following (in MSVC parlance), where the exception filter is a simple boolean expression:
__try { PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....; doSomething(); } __except( (pdwCommStatus||pdwFaultStatus) ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH ) { // handle the exception
}
In include/wine/exception.h, a comment from AJ says that "__EXCEPT(filter_func,param)" is the proper way to do it but "param" is not explained at all and "filter_func must be defined with the WINE_EXCEPTION_FILTER macro", as the comment says. However, a search for WINE_EXCEPTION_FILTER yields no results.
So, how do I do these things in WINE properly? Did I overlook something obvious?
Stefan Kuhr wrote:
In include/wine/exception.h, a comment from AJ says that "__EXCEPT(filter_func,param)" is the proper way to do it but "param" is not explained at all
I think that comment must be very old, the macros don't implement any "param".
So, how do I do these things in WINE properly?
In general, within Wine code, it's impossible. In standard C, a function cannot reference a local variable of another function. It might be possible with some trickery (e.g. declaring explicit register/volatile variables), or with special compiler support (MSVC obviously has special support for it, and perhaps gcc nested functions or something could be used).
For Wine, you'd have to come up with something else. Whatever the filter function needs should be available in some other form than a stack variable, like maybe some global or thread-local (TLS) variable, or perhaps from some function call.
Also perhaps consider whether you need a filter function this complex at all...
Hello Ove,
On Thu, Jul 10, 2008 at 9:55 PM, Ove Kaaven ovek@arcticnet.no wrote:
<snip> In general, within Wine code, it's impossible. In standard C, a function cannot reference a local variable of another function. It might be possible with some trickery (e.g. declaring explicit register/volatile variables), or with special compiler support (MSVC obviously has special support for it, and perhaps gcc nested functions or something could be used).
For Wine, you'd have to come up with something else. Whatever the filter function needs should be available in some other form than a stack variable, like maybe some global or thread-local (TLS) variable, or perhaps from some function call.
Maybe there is something I simply don't understand. What I mean is something like this:
__try { PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....; doSomething(); } __except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) ) { // handle the exception
}
This is something quite common in Win32, as far as I can tell. As an alternative, I would like to use the simple ternary operation in the code snippet in my OP. Maybe I am too ignorant, because I have only coded for Windows the last 15 years and I have some difficulties now trying to prepare a patch for WINE, so bear with me, but I cannot see why that would be trickery.
Also perhaps consider whether you need a filter function this complex at all...
I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this.
Cheers,
I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this.
I hate to be the one to break it to you, but debugging ndrclientCall2 in XP precludes you from contributing to wine's implementation. --Juan
Hi Juan,
On Thu, Jul 10, 2008 at 10:28 PM, Juan Lang juan.lang@gmail.com wrote:
I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this.
I hate to be the one to break it to you, but debugging ndrclientCall2 in XP precludes you from contributing to wine's implementation. --Juan
Oh, I did not know that. What should I do now? Does that mean I can never ever contribute something to improve that function?
Oh, I did not know that. What should I do now? Does that mean I can never ever contribute something to improve that function?
I'm afraid so. --Juan
H everyone,
On Thu, Jul 10, 2008 at 10:34 PM, Juan Lang juan.lang@gmail.com wrote:
Oh, I did not know that. What should I do now? Does that mean I can never ever contribute something to improve that function?
I'm afraid so. --Juan
Stupid me. How could I have prevented that? Is there some sort of 'Code of Ethics' of the WINE project that I should have read before and that tells me not to debug a binary from MS in order to improve a WINE implementation?
Stupid me. How could I have prevented that? Is there some sort of 'Code of Ethics' of the WINE project that I should have read before and that tells me not to debug a binary from MS in order to improve a WINE implementation?
It's on the Developers' FAQ on the wiki: http://wiki.winehq.org/DeveloperFaq#head-fed5011434f62ae1a88baebfb8193a37ea7...
I admit the warning is pretty well buried. It's been discussed here on wine-devel on several occasions, searching for "wine disassembly' will produce one such thread. --Juan
Hi everyone,
On Thu, Jul 10, 2008 at 10:24 PM, Stefan Kuhr winesku@googlemail.com wrote:
Hello Ove,
On Thu, Jul 10, 2008 at 9:55 PM, Ove Kaaven ovek@arcticnet.no wrote:
<snip> In general, within Wine code, it's impossible. In standard C, a function cannot reference a local variable of another function. It might be possible with some trickery (e.g. declaring explicit register/volatile variables), or with special compiler support (MSVC obviously has special support for it, and perhaps gcc nested functions or something could be used).
For Wine, you'd have to come up with something else. Whatever the filter function needs should be available in some other form than a stack variable, like maybe some global or thread-local (TLS) variable, or perhaps from some function call.
Maybe there is something I simply don't understand. What I mean is something like this:
__try { PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....; doSomething(); } __except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) ) { // handle the exception
}
Oh stupid me.
PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....;
should be placed outside the try block.
Hello everyone,
On Thu, Jul 10, 2008 at 10:30 PM, Stefan Kuhr winesku@googlemail.com wrote:
__try { PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....; doSomething(); } __except(MySpecialFilter(GetExceptionCode(),pdwCommStatus, pdwFaultStatus) ) { // handle the exception
}
Oh stupid me.
PDWORD pdwCommStatus = ....; PDWORD pdwFaultStatus = ....;
should be placed outside the try block.
Now that we all know that I cannot contribute anymore to improving NdrClientCall2 and that I also failed to properly write a code snippet that obeys variable scope rules, could someone give an answer to my original problem?
OMG, this afternoon is a real disaster :-(
Thanks,
Now that we all know that I cannot contribute anymore to improving NdrClientCall2 and that I also failed to properly write a code snippet that obeys variable scope rules, could someone give an answer to my original problem?
I think Ove answered it already: basically you can't access a locally-scoped variable from the exception handler in Wine, even if the variable is declared outside the scope of the try block. You'd have to move the variable to some other scope to be able to access it from the exception handler. --Juan
2008/7/10 Stefan Kuhr winesku@googlemail.com:
Now that we all know that I cannot contribute anymore to improving NdrClientCall2 and that I also failed to properly write a code snippet that obeys variable scope rules, could someone give an answer to my original problem?
Hi Stefan,
There is already a bug logged for this issue, but I hadn't got around to implementing it yet. The primary reason being the complexity associated with doing exception handling for one case (objects) without exception handling for the other case (non-object code). There is also the issue of possibly creating conflicts by re-indenting a large chunk of code, but we will just have to suck that up. So leave it with me and I'll let you know when I have something to test.
I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this.
Now that we've established you can't do this yourself, a hint on how you can help us: file a bug describing the problem, and produce as small a test case as you can that shows the problem in Wine. Ideally you can write a regression test that succeeds on Windows and fails on Wine. That should give the devs here a pretty strong hint about what needs to be done.
Thanks, --Juan
Hello everyone,
On 7/10/08, Juan Lang juan.lang@gmail.com wrote:
<snip> Now that we've established you can't do this yourself, a hint on how you can help us: file a bug describing the problem, and produce as small a test case as you can that shows the problem in Wine. Ideally you can write a regression test that succeeds on Windows and fails on Wine. That should give the devs here a pretty strong hint about what needs to be done.
Done, it's Bug #14465. It contains source code and binaries for a windows RPC client and server that allows to use a variety of RPC calls with different comm and fault status decoration of the RPC calls and client side diagnosis of what exceptions are legitimate and what are erroneous. I have also a attached a patch with the result of my work regarding this problem. The source code for this patch has been written before I started debugging the XP implementation of NdrClientCall2 and has been created by analysing the MIDL generated source code for my test project. I hope this all can help to fix this problem. If anyone needs help with my code or my test project, don't hesitate to contact me.
Cheers,
Stefan Kuhr wrote:
This is something quite common in Win32, as far as I can tell.
Yes, like I said, MSVC has special compiler support. In MSVC, __try, __except, etc, are compiler builtins (not macros as in Wine). But they are Microsoft extensions, they can't be implemented using standard C.
Also perhaps consider whether you need a filter function this complex at all...
I need that. I would like to implement comm status and fault status awareness in WINE's rpcrt4, because my applications crash in WINE because of the lack of proper comm status and fault status awareness in WINE's RPC implementation. From debugging NdClientCall2 in XP I deduce I need this.
Well, I'd expect it to be generally better to just have the appropriate exception raised in the first place, rather than conditionally handle it depending on something unrelated to the exception information.
-
Juan Lang -
Ove Kaaven -
Rob Shearman -
Stefan Kuhr