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. 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?
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.
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 you
even know what the -Wl,--no-seh flag does, because I totally fail to see
what connection it has to the discussion at hand here?
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
