On Wed, 22 Apr 2020, Jacek Caban wrote:
On 22.04.2020 12:47, Martin Storsjö wrote:
The compiler doesn't generate .pdata sections if e.g. building with a
toolchain that defaults to SJLJ exception handling - that's a common (not
the most common, but still occurring) configuration.
Like I already wrote once, this is a catch-all handler for catching SEH
exceptions (like crashes and similar) within the mingw code, if SEH isn't
used for the C++ exception handling mechanism. As far as I see it, it's a
nice-to-have feature for those cases.
How reliably can we detect the condition when if compiler will generate
.pdata sections? If it's something like #ifdef __SEH__, then we could
probably use that to limit use of this code inside mingw32 to relevant
builds. It would solve this problem as well and reduce statically linked code
for users that don't need it. It would behave differently than now if other
compiler is used to build crt and use the app using it, but such configs are
shaky anyway.
I think with both Clang and GCC, that you should be able to check for
__SEH__, yes.
That has a fairly high chance of retaining the intended behaviour - so
that's good.
There's of course a chance that my guess for what the code was supposed to
do is wrong, but in any case, if __SEH__ is defined, then both GCC and
Clang do generate .pdata, and the checks would make the code no-op in any
case.
(There's also potential corner cases of using a compiler that uses SEH for
C++ exceptions, but building with -fno-unwind-tables (so that plain C code
doesn't generate unwind info), so it would be possible to construct a
SEH-configured executable without .pdata, but that's really splitting
hairs and not a configuration I think we need to consider.)
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public