On 2020-04-21 19:40, Martin Storsjö wrote:
On Tue, 21 Apr 2020, Jacek Caban wrote:
Hi Steve,
On 21.04.2020 16:40, Steve Lhomme wrote:
windowsapp is meant to replace kernel32, user32, shell32, etc. These
older
libraries should be used with it to avoid linking to entries that
should not
be used in that context (apps working on all win10 devices)
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
When linking with just windowsapp (and a C runtime) there's a call in
mingw32 to RtlAddFunctionTable(). In practice this call has no effect
as the
.pdata of the section takes predecence.
https://pmeerw.net/blog/programming/RtlAddFunctionTable.html
This function call is not allowed an not needed in this context, so
we just
forward the call to an internal dummy version.
Well, the intent of this function call is to synthesize something
corresponding to .pdata, with one huge RUNTIME_FUNCTION for each
executable section in the module, if the executable didn't have any
.pdata of its own, as a global catch-all.
I wouldn't say "is not needed in this context" - it's more like an
optional nice-to-have feature which is totally ok to skip if the runtime
doesn't allow it.
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 functions added come from the PE sections with the
IMAGE_SCN_MEM_EXECUTE flag set. That corresponds to the .text section
"Executable code (free format)":
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#special-sections
I don't know what to make of that but maybe C/C++ code, that are not
dynamic languages always have a hardcoded .pdata section and thus don't
need the hack ? If another language links with mingw32 maybe they can
add the dynamic sections on their own ?
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.
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.
winstorecompat also has a similar function but it should not be used
with
windowsapp as some functions replaced by winstorecompat are now
allowed in
windowsapp.
Hm, wouldn't it make more sense to build separate versions of
winstorecompat, one for 8.x and one for 10?
Not strictly opposed to adding things like into libwindowsapp.a, but as
we have winstorecompat _exactly_ for this purpose, I'd prefer to keep
such dummy fallbacks there, and then build things like
libwinstorecompat10.a if there's a different set of functions to stub out.
We already have similar hacks in the tree already, so if others like
it I won't stay in a way of the patch, but I think that this could be
done better. We should be able to avoid the call in the first place.
One way to achieve that would be to move crt_handler.c to msvcrt
importlib. Then we can customize that for windowsapp crt and avoid
problematic functions.
I don't think particularly that is a good idea here. windowsapp is a
replacement for kernel32 and a few other dlls, but the CRT in this case
is libucrt.a (which links against the api-ms-win-crt-*) which also can
be used for normal desktop things.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
