GkvJwa wrote:
> Sorry for the repeated questions, but I'd really like to understand this
> better :)
>
> In #172287 @efriedma-quic said
>
> > The basic issue here is that you can't generate unwind tables for both SEH
> > and C++ exception handling in the same function.
>
> That makes sense to me.
>
> In our case, we are (as far as I'm aware) building with C++ exceptions
> disabled, so that issue should not apply to us?
>
> That's why I don't understand why this PR gates the
> `err_seh_object_unwinding` diagnostic behind `getLangOpts().EHAsynch`. If the
> problem is mixing SEH and C++ exceptions, why not gate it behind
> `getLangOpts().CXXExceptions`?
>
> > SEH is important for Windows, it can prevent many EXCEPTION_IN_PAGE_ERROR
> > errors. **For LLVM, it only works when using /EHa**
>
> My understanding was that LLVM has had SEH support for a long time, but only
> for synchronous SEH exceptions. I.e. the following should work:
>
> ```
> __try {
> foo(); // Bad memory access in here.
> } __except(EXCEPTION_IN_PAGE_ERROR) {
> // ...
> }
> ```
>
> even without `/EHa` (as long as foo is not inlined)?
>
> > This issue(#62606) can probably answer most questions. The key point is
> > that the handling of SEH in LLVM is not quite the same as in MSVC.
> > Currently, it can be said that with LLVM, the code within the __except
> > block is only explicitly generated when using /eha.
>
> IIUC that issue is about async SEH. We don't build with `/EHa`, but my
> understanding was that synchronous SEH should still work?
I added this code(#62606) snippet to Chromium, and the crash still occurs even
without `/EHa` enabled.
```
#include <stdio.h>
#include <windows.h>
int SafeFetch32(const int* adr, int errValue) {
int v = 0;
__try {
v = *adr;
} __except (EXCEPTION_EXECUTE_HANDLER) {
printf("except\n");
v = errValue;
}
return v;
}
// call this function
SafeFetch32(0, -1);
```
There should be many similar codes in Chromium; for example, the code here also
won't generate SEH information(like `_C_specific_handler`).
https://source.chromium.org/chromium/chromium/src/+/main:sandbox/win/src/process_thread_interception.cc;l=95
Of course, some code does indeed have SEH information because it meets certain
conditions.
Since `/EHa` is not enabled(Can't open it either, has crash), it is impossible
to determine exactly which parts are malfunctioning.
The `/EHa` in LLVM is not equivalent to C++ exceptions or MSVC's SEH, and the
code still has many imperfections.
Ultimately, I prefer to provide a set of SEH parameters rather than putting SEH
within `/EHa`(brought some problems)
https://github.com/llvm/llvm-project/pull/180108
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
