On Wed, 22 Apr 2020, Steve Lhomme wrote:
I am not very familiar with all of this, so don't take my word for it.
It seems the .pdata section to be a Windows only thing
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section
I don't know if gcc/clang/ld/lld handles it or mingw (I would bet on the
former).
In mingw the RtlAddFunctionTable call is only done in libmingw32.a for:
#if defined(__x86_64__) && !defined(_MSC_VER)
So only x64 targets would need a hack.
I see three possibilities
- do not do this call anymore
- do a libmingw32app
- do a winstorecompatapp
#1 would be the cleanest/less invasive solution. Looking at the
__mingw_init_ehandler() the call is only done if the PE headers doesn't
have a .pdata section. If which case would the compiler/linker not
generate such a section ?
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.
Don't suggest just removing code, that someone else has contributed with
some intention, just because you don't understand it.
I don't say that this code is vital for every use case - it isn't, but
suggesting to flat out remove it just because you don't understand isn't
nice. And it's not necessarily a very clean thing, but whoever wrote it
surely had a reason.
Between #2 and #3 I would prefer #2 as for non-x64 the libmingw32app
could just be the same (same binary installed twice) as libmingw32. And
it doesn't force the caller to use winstorecompat (and -DWINSTORECOMPAT)
whenever using libwindowsapp.a.
For this particular case, I don't see why a user would have to build
anything with -DWINSTORECOMPAT - just linking to winstorecompat should be
enough.
When linking with lld, just adding -lwinstorecompat should be enough - lld
looks through libraries in the order they're specified. ld.bfd (GNU ld)
works differently though, so there you'd have to make sure that
-lwinstorecompat is specified after -lmingw32 (but for those cases, you
already now need to edit and use custom spec files anyway).
The problem of #2 is that -lmingw32 is hardcoded in Clang:
https://github.com/llvm-project/clang/blob/master/lib/Driver/ToolChains/MinGW.cpp#L63
Same thing with the gcc spec files:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/crtdll.h#L36
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h#L165
So instead of having libming32.a and libming32app.a we maybe have
libming32.a and app/libming32.a
The linker have to use -L.../libs/app before -L.../libs to make sure it
uses this one. That seems doable in Martin's mingw32uwp toolchain.
Others using windowsapp would have to do it manually.
Out of these two, I _very_ much would prefer #3. I want as much common
code shared between all the potential cases (different crt variants,
desktop/uwp, etc) instead of making more tweaked versions of them.
To you it might seem that adding another copy is "just" a little bit extra
work, but it does add up. And making it different between architectures
(just a copy instead of adding one function) wouldn't be helping, that
also creates even more mess and maintainance burden. The fewer differenes
between architectures, the better.
So far, the intent has been that the base components (crt*.o,
libmingw32.a, libmingwex.a) are common and work for all CRT choices, and
the same should go for desktop/app subsets if winstorecompat is used.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
