[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep on Windows using Clang + MSVC ABI
From: |
David Chisnall |
Subject: |
Re: GNUstep on Windows using Clang + MSVC ABI |
Date: |
Tue, 2 Feb 2021 11:29:59 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
On 01/02/2021 18:24, Frederik Seiffert wrote:
Sorry everyone, looks like my earlier draft got sent out prematurely...
Am 29.01.2021 um 17:28 schrieb David Chisnall
<gnustep@theravensnest.org <mailto:gnustep@theravensnest.org>>:
ld -r is pretty flaky everywhere. LLD wasn't going to implement it at
all and GNUstep was one of only two consumers so I think it's fair to
say that it's pretty likely that it will continue to be intermittently
broken by various linker versions. I personally like the concept but
it's probably better to not depend on it anywhere.
Yeah, hopefully this change will resolve these issues once and for all.
That being said, Richard raised one *potential* issue with this change
on GitHub, which is that it increases the length of the command that the
linker is being called with, as now all subproject object files are
passed directly to the linker. Hopefully OS command line limits are
large enough these days so that this won’t be an issue in practice, but
I’d still encourage everyone to try building their projects with the
"clang-msvc-support" branch of tools-make.
I'm curious about this. GNUstep projects have fairly short linker lines
in comparison with a bunch of C++ projects. I had a quick look at the
systems I have runningL
- FreeBSD limits it to 256 KiB on processes with limited kernel
virtual address space, 512 KiB elsewhere.
- Linux limits it to 128KiB statically but can return a larger number
via sysconf depending on the system. For me, that is around 2MiB.
- Windows limits it to 32 KiB, though cmd.exe only handles 8 KiB.
Even with the 8KiB limit, you'd need a few hundred files on the linker
invocation for this to be a problem unless you're giving long absolute
paths for everything.
Have you tried with the bash.exe in C:\Windows\System32?
I briefly tried building in WSL today, and the main difference to using
an MSYS2 shell is that Autoconf will consider it cross-compiling. This
means that some config checks will not be run (because Autoconf will
think that it can’t run the binaries), and we would need to provide a
cross.config file with pre-determined results of these config files
instead (just like when cross-compiling e.g. for Android). This is
obviously more fragile.
But this kind of illustrates what I consider the biggest challenge with
this setup: the need to install and jump between different shells in
order to build the whole system (i.e. CMD for libobjc2, libdispatch, and
probably others; Bash/MSYS2 for GNUstep).
I’m not sure if there’s an elegant solution to this. My current line of
thinking is to create a project like tools-android (tools-windows?) with
Batch + Bash scripts to build all dependencies and GNUstep in their
respective environments.
Oh, sorry, wrong bash. The one I was thinking of is actually installed
for me as c:\Program Files\Git\git-bash.exe. It's installed by the git
package and gives you a Windows-native bash environment. If the
configure scripts just depend on bash, that ought to be sufficient.
Is the -fuse-ld=lld line required? You get LLD installed when you
install clang, so it's not very important, but the runtime and its
tests, at least, also work with LINK.EXE (though you may have to
disable incremental linking if it's on by default).
I did:
I tried using the MS linker (link.exe), but while that seems to
generally work fine linking ObjC files, it throws up at some
configure tests (specifically when testing "whether objc really
works"). Using LLD works though, so one must run Make configure with
LDFLAGS="-fuse-ld=lld".
This is reproducible simply by compiling config/config.objc.m from
libs-base:
$ clang -o conftest.exe config/config.objc.m -I/c/GNUstep/x64/include
-L/c/GNUstep/x64/lib -fobjc-runtime=gnustep-2.0 -lobjc
LINK : conftest.exe not found or not built by the last incremental link;
performing full link
conftest-b38f3b.o : warning LNK4078: multiple '.CRT' sections found with
different attributes (40400040)
libcmt.lib(initializers.obj) : warning LNK4254: section '.CRT'
(C0000040) merged into '.rdata' (40000040) with different attributes >
$ ./conftest.exe
Segmentation fault
This file appears to depend on objc-common.g, which looks like a
generated file. It probably only needs it for the root-class attribute
(which only raises a warning if it's omitted, so isn't the end of the
world). Aside from that, the file looks like a bunch of the tests that
we have in the libobjc2 repo, which pass in CI, so I'm not sure what's
going on there. Can you add -### to the clang command line and see how
it compares to the same thing for the libobjc2 tests?
$ lldb conftest.exe
(lldb) r
Process 165928 stopped
* thread #1, stop reason = Exception 0xc0000005 encountered at address
0x7ffce04d1048: Access violation reading location 0x00000000
frame #0: 0x00007ffce04d1048 objc.dll`objc_msgSend + 40
objc.dll`objc_msgSend:
-> 0x7ffce04d1048 <+40>: movl (%r10), %r11d
0x7ffce04d104b <+43>: cmpl $0x8, %r11d
0x7ffce04d104f <+47>: je 0x7ffce04d1063 ; <+67>
0x7ffce04d1051 <+49>: cmpl $0x0, %r11d
Let me know if I should open an issue for this somewhere, or if there’s
something in config.objc.m that we should change to fix this.
Please file a libobjc2 bug to track it for now, it might be an LLVM bug,
but I suspect it's something in your environment - it looks as if you're
linking two versions of the Windows C runtime somehow.
For pthreads I have builthttp://www.sourceware.org/pthreads-win32/
<http://www.sourceware.org/pthreads-win32/>from source by invoking
"nmake clean VC" in a VS native tools command prompt, and manually
copied the headers (pthread.h, sched.h, semaphore.h), pthreadVC2.lib
(renamed to pthread.lib), and phtreadVC2.dll.
At some point it would be nice to lose this dependency. I don't know
how much the attitude to C++ in GNUstep has changed recently, but
C++11 now has a nice set of threading abstractions that provide
everything that NSThread, NSLock and friends need. If we use those
instead of pthreads then we'd have something that worked on any
platform with a C++11 implementation (Linux, Windows, Fuschia, Haiku,
and so on).
That’d be nice! I would personally be completely open to using C++ in
GNUstep, and that sounds to me like a much better solution than
implementing NSThread and NSLock with native Windows APIs, although
that’s of course also an option.
I’d appreciate any thoughts on this from others what they think about
C++ in GNUstep to replace specific APIs like pthreads? I guess this
could be guarded with a config check so that a pure-C version would
still be available using pthreads.
Maybe start a new thread for this? This one is very long and I suspect
many people have tuned out.
- NSFileManager support
NSFileManager is currently non-functional with this setup due to
dirent.h missing (MinGW has it, but Windows doesn’t).
I found this MIT-licensed header-only implementation – would that be
ok to add to the project?
https://github.com/win32ports/dirent_h/blob/master/dirent.h
<https://github.com/win32ports/dirent_h/blob/master/dirent.h>
I think that looks easier than using Win32 ABIs directly.
Agreed. I’ll give it a go.
- Autoconf GNUC / GCC / Clang detection
When targeting the MSVC ABI, Clang does not define `__GNUC__`, which
causes Autoconf to not define $GCC (i.e. "checking whether we are
using the GNU C compiler" will be NO). I thus removed $GCC as a
pre-requisite in GS_CHECK_CC_IS_CLANG(), so that Clang is still
correctly detected in this setup.
I *believe* this is controlled by either a gnu dialect (e.g.
-std=gnu11 for C) or -fgnu-extensions. That said, I'm not sure if you
can #include Windows headers with gnu extensions enabled.
Yeah I tried with -fgnuc-version=xxx, but then Windows headers didn’t work.
- Debug/Release CRT
Just a heads up that on Windows the C runtime libraries (CRT) come in
two versions for debug and release builds (e.g. msvcrt and msvcrtd).
The libraries that are used seem to have to match between all DLLs –
e.g. building libobjc2 for debug will cause all sorts of crashes when
Base is build for release, e.g. when freeing memory allocated by
libobjc2 in Base.
Fun.
Indeed. My plan is to link against debug libraries when building with
"make debug=yes".
This is one of the annoying issues with GNUstep Make. Because the build
is configured from the command line invoked in the source directory, not
from the configuration in the build directory, it's very easy to
accidentally mix the two. If I were still actively working on
Objective-C things, I'd be really tempted to replace GNUstep Make with
some CMake packages now that CMake officially supports Objective-C and
using Clang with the GCC-style driver on Windows. It's really nice in
the libobjc2 build that I can generate a Visual Studio project and use
the VS debugger from the CMake.
lld-link: error: relocation against symbol in discarded section:
__start_.objcrt$SEL
>>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init)
This is reproducible when building a file that calls ObjC runtime
functions but doesn’t actually contain any ObjC code. Not sure if
that’s expected behavior or bug.
I think this is a bug, probably a clang bug (and probably my fault)
Should I open an LLVM issue for this?
Yes please. There was an identical bug on ELF platforms, I may have
failed to fix it for Windows.
Awesome work, and it makes me much happier than trying to support MinGW.
Thank you, glad you like it! This is also exciting to us because it
should e.g. allow us to use recent Windows technologies like the
C++/WinRT language projection from ObjC++ which are not compatible with
MinGW.
That being said, I would still very much like to get libobjc2 working
with MinGW as well, as it would allow people currently using GNUstep
with GCC in a MinGW environment to switch to Clang/libobjc2, should
result in a more streamlined setup experience with all dependencies
being available via MinGW packages and everything being built in one
shell, and allow for existing MinGW-based software to be used.
I’ll try to get you those instructions for building LLVM with the MinGW
patches in the next couple weeks.
I'll try to find some time to work on it.
We have given up supporting MinGW for snmalloc and I am considering
optionally supporting snmalloc for Objective-C object allocations
since it is much faster than the system malloc on most platforms and
is particularly good for fixed-size allocations as are common in
Objective-C. It would be a shame for this to be an
everywhere-except-Windows thing.
That looks really great! Would be interesting to see some performance
stats of this for ObjC specifically if you have that.
It depends on the workload, but in the worst case I've seen 2%
improvement relative to jemalloc, in highly concurrent and
allocation-heavy workloads it's been closer to 30%. For parallel and
relatively allocation-heavy workloads it's superlinear relative to the
Windows allocator (improvement increases you add more threads). I don't
have any good Objective-C benchmarks though, so I'll probably make it an
option and let other folks benchmark it on their workloads.
David