Hi,
On Fri, 5 Jun 2020, Steve Lhomme wrote:
Hi,
On 2020-06-04 8:33, Martin Storsjö wrote:
This adds libucrtapp.a, which is the same as libucrt.a, but excluding
libapi-ms-win-crt-private-l1-1-0.a, and with a few statically
linked functions added that otherwise normally are linked from
libapi-ms-win-crt-private-l1-1-0.a.
What is the status of api-ms-win-crt-private-l1-1-0.dll ? Is it always
installed with the UCRT runtime, even on Windows 7 ? If not it should
probably be removed from libucrt.a, otherwise it would lead to builds
with just -lucrt that can't directly be used as a regular UCRT build
done with MSVC.
Yes, it's always installed along with the UCRT. E.g. in Windows
Kits/10/Redist/10.0.*.0/ucrt/DLLs, you have that one along with the
others.
Depending on that, we may or may not need a different version of libucrt.a.
I tried a simple C program (memcpy and strstr) with VS2019 and /MT. The
code that would normally be linked via api-ms-win-crt-private-l1-1-0.dll
is linked via vcruntime140.dll. (even 'memset' which is in
api-ms-win-crt-string-l1-1-0.dll comes from vcruntime140.dll)
So, at least with a recent MSVC the api-ms-win-crt-private* doesn't seem
to be used at all. The "companion" DLL is used instead. Similar to what
is described here with /MT
https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features
libvcruntime.lib and libucrt.lib are used, in that order.
IMO it would be better to have something closer to what MSVC does.
I do see your argument that it'd be nice to match MSVC naming in this
aspect, but I don't think it's worth it in this case:
- MSVC's ucrt.lib doesn't contain any import functions for
api-ms-win-crt-private (as you're required to link in vcruntime
there). But I would prefer to keep api-ms-win-crt-private in our
libucrt.a, at least until these extra functions we add are at least as
good, not just "good compromises". And as a general case, I prefer to link
in as little things statically as possible, when it's available as a
system DLL.
- The way the "default crt" is handled (in mingw-w64-crt, and in gcc and
clang), with the compiler driver automatically adding -lmsvcrt, and with
one single lib*crt*.a of your choice being copied as libmsvcrt.a, I'd
prefer to have all the things bundled up in one .a, so you can choose to
use this variant of UCRT that way if you want to
- If we'd make the vcruntime extra lib an optional addon (like
winstorecompat), you can't know for sure that you don't end up depending
on one of the private functions (if your code ends up calling new
functions we haven't run into yet), so for this case, I want a separate
libucrt*.a without the private bits
- At some point, if our vcruntime/api-ms-win-crt-private replacements are
deemed good enough, we could maybe take it up for discussion about making
it the default for UCRT usage, although that's opposite to what I said
about wanting to link as little statically as possible.
It may be nice to put the musl files in a musl folder so it's easier to
see what comes from there and match with the original source. A git
submodule could also be used.
Well, they have minor modifications (added prototypes for functions that
don't exist in mingw-w64 headers for internal helpers like __strchrnul,
removed weak_alias) and are already in a subdirectory of their own
(string). Having crt function implementations imported from other places
isn't new in mingw-w64-crt either, essentially most of math/* is imported
from various places.
As for the speed of musl, it doesn't seem to bad, at least for strings:
https://www.etalabs.net/compare_libcs.html
Those look decent yeah. My prime concern is for memcpy, where
implementations that use SIMD instructions might be even faster - which
might matter for multimedia applications.
If I understand correctly, one of the reasons of having these string
functions in vcruntime*.dll separately from the fixed UCRT, is that they
want to be able to easier ship newer tuned versions of them.
But I could actually try to make a small benchmark for this, to see if
there's any significant difference (and if the default one from
api-ms-win-crt-private-* that is used right now isn't much faster, it
isn't much of an issue).
I also noticed that api-ms-win-crt-string-* actually does contain memcpy_s
and memmove_s. So we could just have small wrappers that call these
instead, so we'd avoid having to maintain a performance sensitive
implementation of that. That leaves us with a few functions less where we
need a full implementation.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
