On Tue, 2 Apr 2019, Jacek Caban wrote:
On 02/04/2019 22:18, Martin Storsjö wrote:
Regarding the patch itself, it looks like you're losing the longjmp
function altogether from msvcrt.def.in, instead of making it available for
all arches?
No, that was intentional, note that it's defined in msvcrt-common.def.in. Now
that I read it again, ucrtbase.def.in could also be tweaked to use the
version from msvcrt-common.def.in, I will send a new version tomorrow.
Oh, ok, I didn't notice that. Makes sense.
Thank you for the great explanation! It makes perfect sense now.
However, instead of intercepting the longjmp function, it's probably better
to just pass NULL for this parameter to begin with, if SEH isn't available.
With the attached patch, this seems to work fine for me.
So in general, I'd still like to keep x86_64 builds without SEH usable.
(For llvm-mingw, this was the only configuration of x86_64 up until last
summer.) But with the patch I just sent, your patch should be fine (modulo
the misedit in msvcrt.def.in).
Agreed. Your patch is a nice way for supporting that, it looks good to me.
While we're on this subject, is there a reason for providing our own
implementation for ARM? Could we use imported version as well?
I think we could use the imported version for ARM, by making sure we pass
NULL as the second parameter to the setjmp functions.
For ARM64, this doesn't work unless we really use SEH properly. In my own
builds I haven't yet enabled this, but it should be pretty much fully
functional in llvm since around the llvm 8 branch in January. However,
even if SEH is enabled, we'd have to use an "SP on entry" intrinsic to get
the right value for the stack frame parameter, iirc. (The existing kludges
with either mingw_getsp, or __builtin_frame_address(0), don't necessary
return the right value on ARM64.) This is available as an LLVM IR
intrinsic that clang uses, but I don't think it's yet exposed by clang as
a C level intrinsic (as the corresponding setjmp stuff is expanded by the
compiler when operating in msvc mode).
So TL;DR we could maybe get rid of one of them, but the other one is still
not avoidable.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
