x86/Linux progress #7335
Comments
|
\CC @seanshpark @wateret |
|
63607d8 (with alignment workaround) shows the following result: dotnet/coreclr#9121 seems to resolve GC and JIT related failures. |
|
Here is the result from 2ecadf5 (without any additional patch): Recently merged dotnet/coreclr#8849 eliminates the need for alignment workaround. There is a small increase in the number of failed tests, and most of them are caused by stack smashing. Incorrect funclet prolog/epilog may cause this stack smashing issue. |
|
@parjong, @seanshpark, @wateret - I was trying to build and run dotnet for x86 Linux today, using the current state of the master branch, but I was unable to make it work. So I was wondering if you could share a list of steps to successfuly build and gather all parts of the dotnet core the way you do it. |
|
@janvorli It is a bit strange. I have used the same environment (docker container from docker image imported from x86/rootfs in Core CLR). Could you let me know the assert failure that you got? |
|
And, I am currently using a bit old Core FX (although I am not sure whether it is relevant). |
|
The assert and call stack is below. I guess it has to do something with how I've collected all the files. I have created the docker image myself from vanilla Ubuntu 14.04 x86 image and installed all the dependencies, clang, etc. |
|
I'll first check whether master works for me. |
|
To collect Core FX managed dll(s), I used a bit old collecting script of the following form ( |
|
Here is the brief steps that I am currently using:
|
|
@parjong thank you. These match the steps I have done. I guess I'll try to create the docker image from the rootfs as you've said you did to see if it makes any difference. |
|
@parjong it is weird. I have just deleted the whole bin folder in coreclr, rebuilt the sources one more time and now it works. I am sorry for wasting your time. |
|
@janvorli Thanks you for check 👍 FYI, |
|
dotnet/coreclr#9601 (although it is under review) seems to make huge progress. Here is the result XML from b957f8c with dotnet/coreclr#9601: |
|
Here is the result from 6092f90 (log and XML): dotnet/coreclr#9601 seems to make huge progress (more than expected)!!! |
|
@parjong great! Thank you for the update. |
|
@parjong How's it look now? Should we create a Linux/x86 GitHub project (https://github.com/dotnet/coreclr/projects)? It's a relatively new GitHub feature -- not sure how useful it really is. |
|
Here is the result from 2401b6e (full log): dotnet/coreclr#10538 resolves this failure, but is not merged in 2401b6e :
dotnet/coreclr#10188 addresses the following two failures :
dotnet/coreclr#10410 seems to address the following two failures:
The following failures seems to be related with incorrect stack unwinding on esp-frame dotnet/coreclr#10025, or helper-frame dotnet/coreclr#9272). I hope that dotnet/coreclr#10012 addresses these failures:
dotnet/coreclr#10139 is related with these two failures:
The following failure seems to be related with some GC issue, but not sure yet:
|
|
Here is the result from 1c2ee08: As expected, |
|
fa7293a finally resolves most of unittest failures except 2 readytorun tests: Several tests are excluded from the above result. 4 tests based on Windows-specific struct layout rule (#10340)
4 tests related with tailcall optimization:
1 test that takes too much time (about 4 hour?):
4 tests incompatible with remote testing:
1 test that was disabled due to hang before (now it works, but I forgot to enable it)
|
|
bece89e finally shows 0 failed count (although some tests are excluded) |
|
@parjong congratulations for the great progress! Maybe it is time to start running the Pri 1 tests too (that would add about 3000 more tests). |
|
@janvorli We already did. Here is the result from a762db4 (full log): Here is the list of failed tests:
dotnet/coreclr#10340 seems to cause the following failures:
dotnet/coreclr#10888 is expected to resolve the following failures:
GC.Stress.Framework.ReliabilityFramework.ReliabilityFramework is a bit new failure that we need to analyze |
|
@parjong Awesome, thank you! |
|
@parjong The reliability framework is a test that was just re-enabled recently - feel free to ping me sometime with the failure message and I'd be happy to help investigate it if I can. dotnet/coreclr#11029 |
|
@swgillespie Thanks you for comment. GC.Stress.Framework.ReliabilityFramework.ReliabilityFramework failed from 04/20. Both x86 and armel have the same failure. I'm not sure about armhf as I do NOT have a result, yet. |
|
just for the record, my earlier attempt of cross compiling via rootfs and
so something regressed or needs additional work besides setting up rootfs |
|
What is the current status of this? I've tried to cross build Has anyone managed to build a usable .net 6/7 for linux-x86? |
I don't think it was .NET 6, the last working cross compile has been a long time ago, as reported earlier on this thread, and only the runtime not the full SDK. The above regression is still present as of a few months ago when I last tried. |
|
.net6 (at least sudo ./eng/common/cross/build-rootfs.sh x86 bionic
ROOTFS_DIR=`pwd`/.tools/rootfs/x86 ./build.sh --cross --clang9 --arch x86 --runtimeConfiguration Release --librariesConfiguration Release --subset clr.hosts+clr.runtime+clr.jit+clr.corelib+clr.iltools+libs.native+libs.sfx+libs.oob+libs.packagesTo pack artifacts: mkdir runtime_x86
cp artifacts/bin/coreclr/Linux.x86.Release/{corerun,ilasm,ildasm,*.so} runtime_x86
cp artifacts/bin/coreclr/Linux.x86.Release/IL/System.Private.CoreLib.dll runtime_x86
cp artifacts/bin/native/net7.0-Linux-Release-x86/*.so runtime_x86
cp artifacts/bin/microsoft.netcore.app.runtime.linux-x86/Release/runtimes/linux-x86/lib/net7.0/*.dll runtime_x86I've not tested .net7, but .net6 runs simple helloworld successfully. |
|
@gbalykov I'm on branch release/6.0. Subsets |
|
I've checked current main (7d1191e) and it segfaults on xubuntu 18.04 i386 on simple helloworld. However,
Just for reference, to build runtime I use: sudo ./eng/common/cross/build-rootfs.sh x86 bionic
ROOTFS_DIR=`pwd`/.tools/rootfs/x86 ./build.sh --cross --clang9 --arch x86 --runtimeConfiguration Release --librariesConfiguration Release --subset clr.runtime+clr.jit+clr.corelib+clr.iltools+libs.native+libs.ref+libs.src+libs.packages
mkdir runtime_x86
cp artifacts/bin/coreclr/Linux.x86.Release/{corerun,ilasm,ildasm,*.so} runtime_x86
cp artifacts/bin/coreclr/Linux.x86.Release/IL/System.Private.CoreLib.dll runtime_x86
cp artifacts/bin/native/net6.0-Linux-Release-x86/*.so runtime_x86
cp artifacts/bin/microsoft.netcore.app.runtime.linux-x86/Release/runtimes/linux-x86/lib/net6.0/*.dll runtime_x86 |
|
Thanks! With those patches tag |
|
With the above 3 patches, and this one also: I can build a complete SDK for linux-x86 which seems to be functional. The build pipeline, SDKs for .NET 6 and .NET 7 preview 3, and a Nuget feed with the AppHosts etc are here: |
|
Hi @ta264, thanks |
|
@Adinihal just to make sure you didn't miss the main point of the thread, 32bit Linux is (intentionally) not supported by Microsoft but put together by the community, so if your "requirement" implies having support when things break then its better to reject the 32bit requirement as "not supported by Microsoft" rather than putting yourself into a bad spot where you'll have to learn the hard way how to do things yourself. Making an unsupported runtime work on a new (for you) system is not exactly an easy project to get started with Linux. (Just a friendly advice if you didn't read the thread and weren't aware.) |
|
Is there any progress on this? @ta264 Does NativeAOT work with this? |
and others
This issue for tracking x86/Linux progress with respect to the regression tests.
Here is the current status on Ubuntu 14.04 Docker Container (on Ubuntu 16.04 x64) and full result:
The above result comes from 63607d8 with https://github.com/parjong/coreclr/tree/fix/x86_4byte_alignment and dotnet/coreclr#9261.
The text was updated successfully, but these errors were encountered: