On 2020-04-22 14:34, Martin Storsjö wrote:
On Wed, 22 Apr 2020, Steve Lhomme wrote:
On 2020-04-22 12:47, Martin Storsjö wrote:
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.
Indeed, I do not understand it, that's why we're having this discussion.
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.
Indeed, the app doesn't need -DWINSTORECOMPAT, only when compiling
libmingw32.a
Now I don't understand.
You're saying you prefer #2, because with #3 you'd need to define
-DWINSTORECOMPAT.
No. I said I prefer #2 (app/libmingw32.a) because it doesn't force
adding an extra library to link with. You just need to proper path to
the libraries.
Whereas with #3 you need to put -lwinstorecompatapp and -lmingw32 in the
right order.
And now you're saying that in order to compile
libmingw32app.a which is what you want in #2, you would have to compile
it with -DWINSTORECOMPAT?
I think so, in order to unhide then hidden API it calls, in order to
later use windowstorecompatapp. So in the end that ends up compiling
mingw32 twice anyway. The regular one and the one only calling allowed
things and others via whatever winstorecompatapp does.
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.
It's just odd that if the user links with -lwindowsapp (s)he would
also need to add -lwinstorecompatapp when it could be totally hidden.
If it can be hidden and still rely on -lwinstorecompatapp then fine.
The way I see it, -lwindowsapp is a replacement for -lkernel32 and
others - including only the functions that are available there. Then
winstorecompat.a contains stubs for forbidden functions (but it can also
include minimal reimplementations of some functions - case in point
EnumProcessModules). You'd probably practically use them together, but
they are logically separate in my mind. But this isn't a hard blocker
for bundling those object files into libwindowsapp.a - it's just that we
already have these functions in a separate library, winstorecompat, and
we could just build a different subset of it for the win10 case.
The library (with a different subset of forbidden functions) exist. But
it exist for the host app which is free to use not use it. Forcing the
use whenever you link to libwindowsapp.a is a stretch. They might as
well be bundled and hide this completely.
In any case, if it's necessary, one could consider also adding
-lwinstorecompat via my uwp compiler wrappers, if winstorecompat is
supposed to be used together with -lwindowsapp.
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.
What about programs built with `-Wl,--no-seh` ? Like VLC for example.
I have absolutely _zero_ idea what you are trying to say here. And do
It was related to this:
> 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.)
you even know what the -Wl,--no-seh flag does,
No
because I totally fail to
see what connection it has to the discussion at hand here?
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
