Runtime: x86/Linux progress

[parjong]

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:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7027
# Passed           : 5592
# Failed           : 1156
# Skipped          : 279
=======================

The above result comes from 63607d8e657 with https://github.com/parjong/coreclr/tree/fix/x86_4byte_alignment and dotnet/coreclr#9261.

[parjong]

\CC @seanshpark @wateret

[parjong]

63607d8e657 (with alignment workaround) shows the following result:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5892
# Failed           : 856
# Skipped          : 279
=======================
53 minutes and 59 seconds taken to run CoreCLR tests.

dotnet/coreclr#9121 seems to resolve GC and JIT related failures.

[parjong]

Here is the result from 2ecadf5d1ce (without any additional patch):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5874
# Failed           : 874
# Skipped          : 279
=======================
65 minutes and 29 seconds taken to run CoreCLR tests.

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.

[janvorli]

@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.
I have tried to build the coreclr and corefx native binaries both using the cross build and a build inside of a docker container with x86 ubuntu 14.04 (running the container on x64 Ubuntu 14.04). I have built the corefx managed assemblies on my x64 ubuntu.
When I try to run a simple hello world like app inside of the docker container, I get a strange assertion in the native runtime even before the coreclr_initialize completes.

[parjong]

@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?

[parjong]

And, I am currently using a bit old Core FX (although I am not sure whether it is relevant).

[janvorli]

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.
Could you please write down a step by step list of how to get a working environment from scratch?

Assert failure(PID 59096 [0x0000e6d8], Thread: 59096 [0xe6d8]): Consistency check failed: Illegal null pointerFAILED: ok
         FAILED: CheckPointer(pMT)
                /home/janvorli/git/coreclr/src/vm/appdomain.cpp, line: 13816
    File: /home/janvorli/git/coreclr/src/inc/check.h Line: 373
    Image: /home/janvorli/dotnet/test/corerun

#0  DBG_DebugBreak () at debugbreak.S:114
dotnet/coreclr#1  0xf7899a88 in DebugBreak () at /home/janvorli/git/coreclr/src/pal/src/debug/debug.cpp:404
dotnet/coreclr#2  0xf6ce977c in CHECK::Setup (this=0xffffbfa4, message=0xf79daf30 "Illegal null pointer", condition=0xf7a6ba26 "ok",
    file=0xf79daf45 "/home/janvorli/git/coreclr/src/inc/check.h", line=373) at /home/janvorli/git/coreclr/src/utilcode/check.cpp:218
dotnet/coreclr#3  0xf6e3e308 in CheckPointer<MethodTable> (o=0x0, ok=NULL_NOT_OK) at /home/janvorli/git/coreclr/src/inc/check.h:373
dotnet/coreclr#4  0xf7226147 in BaseDomain::LookupType (this=0xf7c9f940 <g_pSharedDomainMemory>, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13816
dotnet/coreclr#5  0xf72260f3 in BaseDomain::LookupType (this=0x8077208, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13813
dotnet/coreclr#6  0xf6f4d993 in VSD_ResolveWorker (pTransitionBlock=0xffffc324, siteAddrForRegisterIndirect=354570792, token=3979264)
    at /home/janvorli/git/coreclr/src/vm/virtualcallstub.cpp:1579
dotnet/coreclr#7  0xf71f349a in ResolveWorkerAsmStub () at asmhelpers.S:1041
dotnet/coreclr#8  0xffffc324 in ?? ()
dotnet/coreclr#9  0xf4fd0222 in ?? ()
dotnet/coreclr#10 0xf633b14c in ?? ()
dotnet/coreclr#11 0xf71f31ab in CallDescrWorkerInternal () at asmhelpers.S:442
dotnet/coreclr#12 0xf6f85d08 in CallDescrWorker (pCallDescrData=0xffffcba8) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:146
dotnet/coreclr#13 0xf6f85ab9 in CallDescrWorkerWithHandler (pCallDescrData=0xffffcba8, fCriticalCall=0) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:89
dotnet/coreclr#14 0xf6f87a2b in MethodDescCallSite::CallTargetWorker (this=0xffffcdd8, pArguments=0xffffcf00, pReturnValue=0xffffcc18, cbReturnValue=8)
    at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:656
dotnet/coreclr#15 0xf6d56064 in MethodDescCallSite::Call_RetOBJECTREF (this=0xffffcdd8, pArguments=0xffffcf00) at /home/janvorli/git/coreclr/src/vm/callhelpers.h:436
dotnet/coreclr#16 0xf7205fd4 in AppDomain::DoSetup (this=0x8077208, setupInfo=0xffffd2f8) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:5735
dotnet/coreclr#17 0xf6d4a3cc in CorHost2::_CreateAppDomain (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336, wszAppDomainManagerAssemblyName=0x0,
    wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958, pAppDomainID=0xffffd650)
    at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1717
dotnet/coreclr#18 0xf6d4d9ac in CorHost2::CreateAppDomainWithManager (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336,
    wszAppDomainManagerAssemblyName=0x0, wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958,
    pAppDomainID=0xffffd650) at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1890
dotnet/coreclr#19 0xf6cd1623 in coreclr_initialize (exePath=0x8052014 "/home/janvorli/dotnet/test/corerun", appDomainFriendlyName=0x804e529 "unixcorerun", propertyCount=5,
    propertyKeys=0xffffd694, propertyValues=0xffffd680, hostHandle=0xffffd654, domainId=0xffffd650)
    at /home/janvorli/git/coreclr/src/dlls/mscoree/unixinterface.cpp:219
dotnet/coreclr#20 0x0804c51f in ExecuteManagedAssembly (currentExeAbsolutePath=0x8052014 "/home/janvorli/dotnet/test/corerun",
    clrFilesAbsolutePath=0x8052084 "/home/janvorli/dotnet/test", managedAssemblyAbsolutePath=0x805204c "/home/janvorli/dotnet/test/nullref.exe",
    managedAssemblyArgc=0, managedAssemblyArgv=0x0) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcoreruncommon/coreruncommon.cpp:404
dotnet/coreclr#21 0x0804b228 in corerun (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:149
dotnet/coreclr#22 0x0804b35a in main (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:161

[parjong]

I'll first check whether master works for me.

[parjong]

To collect Core FX managed dll(s), I used a bit old collecting script of the following form (OS is Linux):

MANAGED_TAGS=()
MANAGED_TAGS+=("AnyOS.AnyCPU")
MANAGED_TAGS+=("Unix.AnyCPU")
MANAGED_TAGS+=("${OS}.AnyCPU")

    for MANAGED_TAG in ${MANAGED_TAGS[@]}; do
      REPO="${SRC_DIR}/${MANAGED_TAG}.${PRESET}"

      for BASE in $(find "${REPO}"  -iname '*.dll' \! -iwholename '*test*' \! -iwholename '*/ToolRuntime/*' \! -iwholename '*/RemoteExecutorConsoleApp/*' \! -iwholename '*/net*' \! -iwholename '*aot*' -exec dirname {} \; | uniq | xargs -i basename {}); do
        PDB_FILE="${REPO}/${BASE}/${BASE}.pdb"
        DLL_FILE="${REPO}/${BASE}/${BASE}.dll"

        if [[ -f "${DLL_FILE}" ]]; then
          cp -t "${MANAGED_BIN_FILE_INTO}" "${DLL_FILE}"
        fi
      done
    done

[parjong]

Here is the brief steps that I am currently using:

• Cross-build Core CLR with the following command and copy the artifacts into output directory:

coreclr $ ./build.sh cross x86  skipnuget debug cmakeargs "-DSKIP_LLDBPLUGIN=true" clang3.8
...
$ cp bin/Product/Linux.x86.Debug/* [OUTPUT DIR]

• Collect Core FX native so(s)

corefx $  cp bin/Linux.x86.Debug/* [OUTPUT DIR]

• Collect Core FX managed dll(s) using the above script

[janvorli]

@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]

@janvorli Please let me know if there is any problem. I checked the current tip (7f3a87ae63b88327a3dc2b830d52f49a480509e0) and it works for me.

[janvorli]

@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.
Btw, I have not specified the "-DSKIP_LLDBPLUGIN=true" and the libsosplugin.so was also built fine.

[parjong]

@janvorli Thanks you for check :+1:

FYI, -DSKIP_LLDBPLUGIN=true was just a workaround during bring up, but remains unchanged as lldb-plugin is not used currently.

[parjong]

Here is the result (XML) from b957f8c3e3b:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7027
# Passed           : 5913
# Failed           : 833
# Skipped          : 281
=======================

[parjong]

dotnet/coreclr#9601 (although it is under review) seems to make huge progress.

Here is the result XML from b957f8c3e3b with dotnet/coreclr#9601:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6526
# Failed           : 220
# Skipped          : 281
=======================

[parjong]

Here is the result from 6092f90e5a0 (log and XML):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6614
# Failed           : 131
# Skipped          : 282
=======================

dotnet/coreclr#9601 seems to make huge progress (more than expected)!!!

[parjong]

dc3626d4e69 finally achieves < 100 failures:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6657
# Failed           : 88
# Skipped          : 282
=======================

Here are log and XML.

[janvorli]

@parjong great! Thank you for the update.
CC: @gkhanna79

[parjong]

Here is the recent result (XML) from cf7d6d92484:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6707
# Failed           : 51
# Skipped          : 269
=======================

[BruceForstall]

@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.

[parjong]

Here is the result from 2401b6ed082 (full log):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7061
# Passed           : 6319
# Failed           : 18
# Skipped          : 724
=======================

dotnet/coreclr#10538 resolves this failure, but is not merged in 2401b6ed082 :

• Loader/classloader/generics/Instantiation/Recursion/genrecur/genrecur.sh

dotnet/coreclr#10188 addresses the following two failures :

• JIT/Methodical/eh/nested/nonlocalexit/throwinfinallyrecursive_20_d/throwinfinallyrecursive_20_d.sh
• JIT/Methodical/eh/nested/nonlocalexit/throwinfinallyrecursive_20_r/throwinfinallyrecursive_20_r.sh

dotnet/coreclr#10410 seems to address the following two failures:

• JIT/Performance/CodeQuality/Serialization/Deserialize/Deserialize.sh
• JIT/Performance/CodeQuality/Serialization/Serialize/Serialize.sh

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:

• JIT/IL_Conformance/Old/Conformance_Base/conv_ovf_r8_i/conv_ovf_r8_i.sh
• JIT/IL_Conformance/Old/Conformance_Base/conv_ovf_r8_i4/conv_ovf_r8_i4.sh
• JIT/Methodical/Arrays/misc/_il_relinitializearray/_il_relinitializearray.sh
• JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b52578/b52578/b52578.sh
• JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b52840/b52840/b52840.sh
• JIT/Regression/CLR-x86-JIT/V1.1-M1-Beta1/b143840/b143840/b143840.sh
• JIT/Regression/VS-ia64-JIT/V1.2-M01/b12390/b12390/b12390.sh
• JIT/jit64/rtchecks/overflow/overflow01_div/overflow01_div.sh
• JIT/jit64/rtchecks/overflow/overflow02_div/overflow02_div.sh
• JIT/jit64/rtchecks/overflow/overflow04_div/overflow04_div.sh

dotnet/coreclr#10139 is related with these two failures:

• readytorun/mainv1/mainv1.sh
• readytorun/mainv2/mainv2.sh

The following failure seems to be related with some GC issue, but not sure yet:

• JIT/Performance/CodeQuality/Span/SpanBench/SpanBench.sh

[parjong]

Here is the result from 1c2ee08a4bc:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7061
# Passed           : 6320
# Failed           : 17
# Skipped          : 724
=======================

As expected, Loader.classloader.generics.Instantiation.Recursion.genrecur.genrecur failure is gone:

Failed test:
  JIT.IL_Conformance.Old.Conformance_Base.conv_ovf_r8_i.conv_ovf_r8_i
  JIT.IL_Conformance.Old.Conformance_Base.conv_ovf_r8_i4.conv_ovf_r8_i4
  JIT.Methodical.Arrays.misc._il_relinitializearray._il_relinitializearray
  JIT.Methodical.eh.nested.nonlocalexit.throwinfinallyrecursive_20_d.throwinfinallyrecursive_20_d
  JIT.Methodical.eh.nested.nonlocalexit.throwinfinallyrecursive_20_r.throwinfinallyrecursive_20_r
  JIT.Performance.CodeQuality.Serialization.Deserialize.Deserialize
  JIT.Performance.CodeQuality.Serialization.Serialize.Serialize
  JIT.Performance.CodeQuality.Span.SpanBench.SpanBench
  JIT.Regression.CLR-x86-JIT.V1-M12-Beta2.b52578.b52578.b52578
  JIT.Regression.CLR-x86-JIT.V1-M12-Beta2.b52840.b52840.b52840
  JIT.Regression.CLR-x86-JIT.V1.1-M1-Beta1.b143840.b143840.b143840
  JIT.Regression.VS-ia64-JIT.V1.2-M01.b12390.b12390.b12390
  JIT.jit64.rtchecks.overflow.overflow01_div.overflow01_div
  JIT.jit64.rtchecks.overflow.overflow02_div.overflow02_div
  JIT.jit64.rtchecks.overflow.overflow04_div.overflow04_div
  readytorun.mainv1.mainv1
  readytorun.mainv2.mainv2

[parjong]

fa7293aa828 finally resolves most of unittest failures except 2 readytorun tests:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7068
# Passed           : 6343
# Failed           : 2
# Skipped          : 723
=======================

Several tests are excluded from the above result.

4 tests based on Windows-specific struct layout rule (#10340)

• Interop/MarshalAPI/OffsetOf/OffsetOf/OffsetOf.sh
• JIT/Directed/RVAInit/nested/nested.sh
• JIT/Directed/RVAInit/simple/simple.sh
• JIT/Regression/CLR-x86-JIT/V1.2-Beta1/b103058/b103058/b103058.sh

4 tests related with tailcall optimization:

• JIT/Directed/tailcall/tailcall/tailcall.sh
• JIT/Methodical/tailcall_v4/hijacking/hijacking.sh
• JIT/Methodical/tailcall_v4/smallFrame/smallFrame.sh
• JIT/Regression/JitBlue/devdiv_902271/DevDiv_902271/DevDiv_902271.sh

1 test that takes too much time (about 4 hour?):

• JIT/Performance/CodeQuality/Burgers/Burgers/Burgers.sh

4 tests incompatible with remote testing:

• JIT/CheckProjects/CheckProjects/CheckProjects.sh
• JIT/Performance/CodeQuality/BenchmarksGame/k-nucleotide/k-nucleotide/k-nucleotide.sh
• JIT/Performance/CodeQuality/BenchmarksGame/regexdna/regexdna/regexdna.sh
• JIT/Performance/CodeQuality/BenchmarksGame/revcomp/revcomp/revcomp.sh

1 test that was disabled due to hang before (now it works, but I forgot to enable it)

• JIT/Performance/CodeQuality/Roslyn/CscBench/CscBench.sh

[parjong]

bece89ead08 finally shows 0 failed count (although some tests are excluded)

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7068
# Passed           : 6345
# Failed           : 0
# Skipped          : 723
=======================

[janvorli]

@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).

[parjong]

@janvorli We already did. Here is the result from a762db4d403 (full log):

=======================
     Test Results
=======================
# Tests Discovered : 11346
# Passed           : 10528
# Failed           : 7
# Skipped          : 811
=======================

Here is the list of failed tests:

• CoreMangLib.cti.system.runtime.interopservices.marshal.MarshalSizeOf1_PSC.MarshalSizeOf1_PSC
• CoreMangLib.cti.system.runtime.interopservices.marshal.MarshalSizeOf2_PSC.MarshalSizeOf2_PSC
• CoreMangLib.cti.system.intptr.IntPtrToInt64.IntPtrToInt64
• CoreMangLib.cti.system.string.StringChars.StringChars
• CoreMangLib.cti.system.uintptr.UIntPtrCtor_UInt64.UIntPtrCtor_UInt64
• CoreMangLib.cti.system.uintptr.UIntPtrToUInt32.UIntPtrToUInt32
• GC.Stress.Framework.ReliabilityFramework.ReliabilityFramework

dotnet/coreclr#10340 seems to cause the following failures:

• CoreMangLib.cti.system.runtime.interopservices.marshal.MarshalSizeOf1_PSC.MarshalSizeOf1_PSC
• CoreMangLib.cti.system.runtime.interopservices.marshal.MarshalSizeOf2_PSC.MarshalSizeOf2_PSC

dotnet/coreclr#10888 is expected to resolve the following failures:

• CoreMangLib.cti.system.intptr.IntPtrToInt64.IntPtrToInt64
• CoreMangLib.cti.system.string.StringChars.StringChars
• CoreMangLib.cti.system.uintptr.UIntPtrCtor_UInt64.UIntPtrCtor_UInt64
• CoreMangLib.cti.system.uintptr.UIntPtrToUInt32.UIntPtrToUInt32

GC.Stress.Framework.ReliabilityFramework.ReliabilityFramework is a bit new failure that we need to analyze

[janvorli]

@parjong Awesome, thank you!
CC: @gkhanna79, @Petermarcu

[swgillespie]

@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. https://github.com/dotnet/coreclr/pull/11029

[parjong]

@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.

[Petermarcu]

@parjong Awesome progress!

[parjong]

@gkhanna79 This issue is just for discussion and progress tracking. Could you please change the milestone, or should I close this one?

[gkhanna79]

I have changed the milestone - please continue to use this for discussion.

[ryukinix]

Awesome. This may be released with 2.0.0 .NET Core?

[BruceForstall]

@parjong @seanshpark and others: I haven't seen any Linux/x86 activity lately. Are people still working on this or using this? Should I still try to find time to review https://github.com/dotnet/coreclr/pull/10034 (Enable FEATURE_FIXED_OUT_ARGS), for example?

[parjong]

Yes, we are using x86/Linux CLR, but we are currently not working on dotnet/coreclr#10034.

We have tested CLR daily, and there have been no failed tests except tests related with dotnet/coreclr#10340 (for Debug/Checked/Release) from May.

We also have tested FX, and x86/Linux and x64/Linux are almost same (except some CompilerService tests related with dotnet/coreclr#10340) for 2.0.0 branch, but we recently have some more failures on x86/Linux for master branch.

[TheLastRar]

Are there any plans to start doing x86/Linux daily builds?

[seanshpark]

@TheLastRar , could https://github.com/dotnet/coreclr/pull/12897 be the one ?

[realityexists]

So is it possible to download an x86 Linux build somewhere? And how stable/safe to use is it?

[parjong]

@realityexists x86/Linux CLR is not released yet, and thus I think that you need to build it by yourself.
It is also hard to say about its safety, but we haven't encountered a blocking issue, yet.

[philippweidhas]

@parjong to build x86 Linux, wich of the github projects i have to clone? Is it the normal https://github.com/dotnet/coreclr or a other project? Im not sure where to begin. Thanks for your help

[ryukinix]

I have interest on this too. Would be nice a guide how to build dotnet on Linux.

[parjong]

@philippweidhas @ryukinix https://github.com/dotnet/coreclr/issues/13192#issuecomment-320188913 may be helpful.

You also need to build Core FX (https://github.com/dotnet/corefx) to run an C# application. https://github.com/dotnet/coreclr/issues/9265#issuecomment-280519593 and https://github.com/dotnet/coreclr/issues/9265#issuecomment-280521257 may be helpful.

Unfortunately, dotnet is not supported, yet. You may use corerun (which this repo provides) instead.

[philippweidhas]

@parjong @ryukinix i could succesfully build coreclr for x86 but im struggling to build Core FX with:

sudo apt-get install debootstrap
sudo apt-get install qemu-user-static
sudo ./cross/build-rootfs.sh x86
sudo apt-get install cmake
sudo apt-get install clang-3.8 lldb-3.8
./build.sh cross x86 skipnuget debug cmakeargs "-DSKIP_LLDBPLUGIN=true" clang3.8

do i have to build the CoreFX project on another way?

[seanshpark]

but im struggling to build Core FX with

Could you paste what the problem(error) is? Or it would be better to add a new issue and talk at there.

[seanshpark]

This is how I've checked with latest master as of writing this;

# build native codes for host (x64) first
./build-native.sh -debug -- clang3.8

# and then build native codes for x86-32 
./build-native.sh -debug -buildArch=x86 -- cross clang3.8

# build managed codes but not the tests
./build-managed.sh -BuildTests=false

These commands are from some time ago and not sure it's the latest.

[ryukinix]

Or it would be better to add a new issue and talk at there.

I think is better, since this issue thread is only about the development progress of x86.

[philippweidhas]

@parjong @seanshpark @ryukinix Hi guys i opened an new Issue for the x86 build for CoreFX in the CoreFX repository, i think that is the better place to discuss this problem.

[dmitriyse]

Most of linux distributives dropping x86 support. Please consider to support x32 ABI runtime (only for linux hosts). See https://en.wikipedia.org/wiki/X32_ABI. Ubuntu 16.04 already supports it. (apt install libc6-x32)

Windows 10 looks like have no plans to kill 32 bit version, but at the same time have no any plans to support x32 ABI.

[ryukinix]

Most of linux distributives dropping x86 support

This is quite true, unfortunately most of the distributions (like Arch
Linux) is indeed dropping x86 support. Debian probably will continue

supporting that, but I'm not so sure about the others.

As lembranças não são só do passado. Podem ser de agora e até de
amanhã.
— Serial Experiments Lain
Manoel Vilela,
Discente em Engenharia da Computação,
Universidade Federal do Ceará.

On Wed, Nov 15, 2017 at 1:24 PM, dmitriyse [e-mail]
wrote:

Most of linux distributives dropping x86 support. Please consider to
support x32 ABI runtime (only for linux hosts). See
https://en.wikipedia.org/wiki/X32_ABI. Ubuntu 16.04 already supports
it. (apt install libc6-x32)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

@seanshpark, @parjong, if all tests are passing since August 2017, what is remaining? Although everyone is talking about support disappearing, Cannonical will support 32-bit until 2023 via Ubuntu 18: https://itsfoss.com/ubuntu-32-bit-support-drop/. CentOS still has community driven 32 bit. It may take 10-15 years before it is absolutely gone from all the mainstream traditional hosting servers (some of which are still running old centos). But if dotnet is ready for 32-bit, why not just ship it like Mono does?

[borgdylan]

Support for 32-bit installation is disappearing but support for 32-bit libraries on x64 installations will still be supported for the forseeable future. Said libraries are needed to run 32-bit code on x64 installations. With those 32-bit .NET Core would still be able to run, probably faster if runnign a small application without a huge hunger for memory.

[deinok]

I'm trying to run .NET Core Apps on an Intel Galileo , exactly on a IOT2000

So I have to use Mono, but I would like to use netcore directly.
Is corerun ready for execute netcoreapp2.1?

[borgdylan]

AFAIK, 32-bit packages have not been published and there has been no annoucement on when those will be available. The latest architecture to be officially supported along with x64 is ARM32 (ARMv7+).

[ghost]

x64 is ARM32 (ARMv7+)

and aarch64.

I think we can build end to end i386 product by ourselves using https://github.com/dotnet/source-build. buildbootstrapcli.sh --rid linux-x86 ..., see https://github.com/dotnet/source-build/blob/master/Documentation/boostrap-new-os.md#building-the-bootstrap-cli. I haven't gotten a chance to setup x86 VM to build it yet, but should be straight forward @deinok.

[liserdarts]

I think we can build end to end i386 product by ourselves

If you're going to build it yourself you might be interested in the repository I made specifically for this situation.

In there is a bash script that will download the source, build, and create an output folder. It runs on x64 in Linux and builds .NET Core for x86 in Linux,

As far as what's left for x86 support, there is on thing I'm aware of. In an v2.1-preview1/Linux/x86 environment it's possible to crash the processes when using NamedPipeServerStream. I think this is an issue for corefx and there is an open issue for it.

Not sure if this has been fixed in v2.1-preview2 or v2.1-rc1. I you're interested in testing those branches yourself I have create a repo that reproduces the problem.

[ghost]

I think what you have achieved is essentially a subset of https://github.com/dotnet/source-build, which is meant for distribution package managers and other source builders. It builds 20 submodule repositories, including dotnet, aspnet and microsoft orgs. I think it would be best to converge the effort into that repo for more platforms rather than reinventing it.

[weltkante]

What is up with this? this doc says to check runtime.json for supported runtime identifiers. I see linux x86 variants in there, but can't get them to work on my ubuntu sandbox.

Missing x86 support has been holding me back from porting my servers from mono/desktop framework builds to .NET Core builds, because x64 memory usage is nearly doubling the runtime memory usage.

[sergei66666]

Hello to all! I would also like to use x86. What problems stand in the way to the x86 future?

[danmosemsft]

@jkotas @janvorli

[jkotas]

Linux x86 is community supported at this point. There are no officially supported prebuilt binaries available. You have to build your own as others commented above.

Thank you for your feedback. We will consider adding prebuilt .NET Core Linux x86 binaries in future if we see a lot of demand for them. Please leave comment on this issue if you would like to see .NET Core officially supported on Linux x86.

cc @richlander

[ikkentim]

I would love to see prebuilt binaries :)

[TheLastRar]

I would like to see prebuilt packages as well, preferably in a manor that supports multiarch.

[deinok]

@jkotas Probably it could be cool to at least have the initial dotnet to start trying compile from a linux-x86 host

[bording]

I'd actually prefer to not see official x86 linux binaries, primarily because then I'd feel obligated to build even more native binaries to make LibGit2Sharp work with them! 😄

[deinok]

@bording And Mono? It runs in x86
Im not sure if this is a good reason for not having an unofficial x86 runtime / sdk.

An important point is that some industrial enviroments are move to have PLC with linux and most of them have a x86 arch. And industrial environments wont change its arch in a looooong time.
Ex: https://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/Pages/Default.aspx?tabcardname=simatic%20iot2000%20io-shield

[bording]

@bording And Mono? It runs in x86
Im not sure if this is a good reason for not having an unofficial x86 runtime / sdk.

True, though at this point I'm considering .NET Core the primary platform for non-Windows support in LibGit2Sharp. Mono doesn't have a way to provide a single NuGet package that has all the binaries needed for different distros that works without some manual intervention.

But that's getting off-topic here, so I'l leave it at that!

[cocowalla]

@jkotas another vote for a linux-x86 rid. I've been following this issue since it was opened back in 2017, and it's disappointing that Linux x86 still isn't officially supported. I get that most platforms are x64 nowadays, but x86 will be around for a long time before it goes away.

IIRC, even the guidance for Azure App Service recommends using 32-bit instead of 64-bit, because of the memory savings.

[ntindle]

Another vote for it. Power shell requires it. @jkotas
dotnet/core#322

[weltkante]

It would be great if we could at least have documented how to do custom builds. I've been trying repeatedly and not been able to setup custom 32 bit builds (custom builds of individual git repos work but I could never get the whole system run together).

[jkotas]

documented how to do custom builds.

https://github.com/dotnet/source-build has the script and documentation to build the whole system. Have you tried that?

This will get a lot easier with https://github.com/dotnet/coreclr/issues/26175

[weltkante]

Thanks, I'll try that (and report back for anyone else interested), so far I only looked at individual repository readmes and various (outdated) blog posts, didn't see that yet. The last time I got stuck in figuring out how to get corefx build pick up the coreclr build output.

[deinok]

@jkotas Can we know when will the plataform merge will start?

[jkotas]

It is best to ask on dotnet/coreclr#26175 about the timelines. It started already: folks are figuring the execution details, the tools and techniques to use, etc.

[weltkante]

@jkotas doesn't look like source-build supports cross compiling, bootstrap looks promising but seems to need a pure x86 Ubuntu instead of using x86_64 and is more complex than it needs to be for the special case of a Linux x86 build. I'll continue experimenting over the weekend, but its far from being a useable documentation/tool for creating x86 builds on Linux. I've created dotnet/source-build#1235 for further discussion on how to do custom builds, perhaps the documentation (or scripts) can be improved as a result of that.

[janvorli]

@weltkante you don't need a pure x86 Ubuntu to build. You can use cross compilation - first build rootfs using the eng/common/cross/build-rootfs.sh script for x86 (run it on x64) and then use it for cross compiling.

[janvorli]

If you wanted to try to use the bootstrap script though, you'd need to patch it a bit so that it can do cross build. You'd need to add -cross option to the coreclr build.sh and the corefx build-native.sh and --cross to the core-setup build.sh and before running the script, set ROOTFS_DIR env var to point to the location of the rootfs you've built for x86.

[ikkentim]

@jkotas any news on the prebuilt .NET Core Linux x86?

Also, is there an issue on dotnet/runtime for this topic (Linux x86), or does discussion continue here?

[weltkante]

@ikkentim I think dotnet/source-build#1235 I created above may be the appropriate place for discussing how to get it working (unless its also merged into dotnet/runtime? I'm not entirely sure). The repository already contains build scripts for x86 but they are underdocumented and unfortunately I couldn't get them completing successfully by trial-and-error. Before any prebuilt packages can be made the build scripts need to be put into working order.

For what its worth coreclr itself is easy to compile for x86 (you can do this with the existing build scripts in the coreclr build tree), but getting a build for the rest of the dotnet infrastructure is the problem.

[jkotas]

is there an issue on dotnet/runtime for this topic (Linux x86)

We have not bulk migrated the issues from the coreclr/corefx repos to dotnet/runtime yet. It should happen any day now. Just use the the existing Linux x86 issue in coreclr for any discussion on this.

dotnet/runtime is the place to focus on. Can dotnet/runtime be cross-compiled for Linux x86 right now?

If you just need the runtime (without the full SDK), dotnet/runtime is all that needs to be build. source-build should not be necessary for that.

[sos-dll]

Can dotnet/runtime be cross-compiled for Linux x86 right now?

I read some comments from 2017, claiming they have compiled x86 Linux runtime at that time...
So, I just been trying to accomplish the same today, but despite all the efforts -- failed.
There must be something missing on the cross-compiling page (i.e. a package, binutils-i686-linux-gnu is not listed for x86 arch), and there's also something wrong with the information there (dated perhaps?)...
For example:

If I run this command in terminal, I receive permission denied error, meaning sudo is missing.
Furthermore, after running the above command with sudo, the following is printed:

MSBUILD : error MSB1018: Verbosity level is not valid.
Switch: verbose
For switch syntax, type "MSBuild -help"

Adding up such things (errors/quirks), makes me believe the information on the cross-compiling page is incorrect/dated.
If there were a notice about the information being incorrect/dated, I wouldn't have even tried to do this. Anyways, there goes over 6 hours, wasted for nothing.
/rant

I, too, would appreciate an actual support for x86 Linux!
There being no other option since there is no support for x86 Linux, I have to go with mono instead.
Too bad.

(Here's the dump from last command I had executed, if anyone want to examine: build.html.txt)

[weltkante]

Compiling the runtime wasn't an issue before the repository merge, you could cross-compile the coreclr repo exactly as specified in the instructions (I assume you still can if you use the old repo instead of the merged one). The problem was doing anything useful with it, since coreclr doesn't build the libraries or SDK. Cross compiling corefx or building the SDK didn't work out so well, never got it working (see previous few posts and the issue I created over at the source-build repo). You need at least corefx to do anything useful because it contains some architecture specific libraries.

As far as the merged repository is concerned it looks like the cross compiling instructions have been updated, I suspect since x86 isn't officially supported something got broken (or just not updated) in the scripts.

Considering I got it working before I'll have another look and see if I can figure out what is broken. Your error log seems to say that no architecture was passed along at all.

Its awful that there is no official x86 or x86_64 support, we're still running servers on mono because x64 applications require twice the memory. While I understand that pure x86 OS are phased out I don't understand why nobody goes for the low hanging fruit of optimizing memory usage by allowing building x86_64 applications. Needing twice the number of servers in the cloud _is_ a significant enough cost that we don't upgrade some deployments to .NET Core.

[cocowalla]

@weltkante just wanted to chime in with another voice, in full agreement.

Even when you run App Services in Microsoft Azure, they are 32-bit by default - presumably for memory efficiency.

x86 support does seem like low hanging fruit that I would have thought was relatively straightforward for the core team to add, but obviously more difficult for 3rd parties who won't have that same level of knowledge.

[weltkante]

Following the instructions on the crosscompile page can build coreclr for x86 cleanly on current master, like it used to in the old repo. I agree there are minor mistakes (like the verbosity switch or where rootfs is generated) but all were obvious to fix (build.sh --help tells you the verbosity levels and the rootfs generator displays where it really put the files). Not sure where exactly @sos-dll went wrong, but it was important to pay attention to the details in the instructions, copy pasting command lines does not work, some things are spelled out textually.

Actually now that corefx and coreclr are in the same repo I got corefx cross compiled for the first time ever. 🎉 It was straightforward, I only had to adjust the subset switch on the main build script.

NOTE: I did not try running anything with the output of the crosscompile build since I have no idea how to use the build output

Now I could probably go ahead and just try figuring out how to use the build output, but I'll take a break here and instead spend some more time researching if I can build a full SDK. I feel we're pretty close to being able to have working x86. 🚀

if you want to follow along and do your own experiments

...

• fresh Ubuntu 18.04 cloud VM with 32gb RAM (I had OOM killer activate with 16gb last year on my physical machine so didn't want to risk wasting my time by being stingy on memory)
• installing cmake and dependencies as explained here.
  
  
  
  • wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /etc/apt/trusted.gpg.d/kitware.gpg >/dev/null
  
  
  • sudo apt-add-repository 'deb https://apt.kitware.com/ubuntu/ bionic main'
  
  
  • sudo apt-get update
  
  
  • sudo apt-get upgrade
  
  
  • sudo apt-get install cmake llvm-9 clang-9 autoconf automake libtool build-essential python curl git lldb-6.0 liblldb-6.0-dev libunwind8 libunwind8-dev gettext libicu-dev liblttng-ust-dev libssl-dev libnuma-dev libkrb5-dev zlib1g-dev
  
  
• sudo apt-get install debootstrap qemu-user-static
  Minimum additional dependencies for cross compilation, had those in my notes, the official documentation is here.
• git clone https://github.com/dotnet/runtime.git dotnet-runtime-x86
• cd dotnet-runtime-x86
• sudo ./eng/common/cross/build-rootfs.sh x86
• export ROOTFS_DIR=/home/username/dotnet-runtime-x86/.tools/rootfs/x86
  don't forget to insert the right username ;-)

Now you can build either

• just the runtime
  ./build.sh --subset clr.runtime --arch x86 --cross
• coreclr+corefx
  ./build.sh --subset clr+libs --arch x86 --cross
• nuget packages
  ./build.sh --subset clr+libs+corehost+installer.pkgprojs --arch x86 --cross
• full repo
  ./build.sh --arch x86 --cross

If you need detailed console output you can add --verbosity detailed (or some other level of your choice)

For what its worth I first was trying to build the release/5.0-preview5 branch but that failed; master succeeded (commit 4224c4c16274b99791fbcc4e8fc987e64c4aaead)

[edit] streamlined the above workflow a bit after going through it a second time and making sure things work as expected

[sos-dll]

@weltkante
I tried this again. Got the same error.
bash-dump.html.txt

edit
So, I decided to check out the same commit version as you mentioned.
And after running the same build command... Bizarre discovery here.

.... 🤔 ....
Finally! 🚀

[Jopacari]

Hi.

Having support for 32 bit is still relevant especially for efficient code running on containers or in VMs on the cloud. Reducing the memory footprint still has a significant impact on resources and cost.
Any new on this matter?

Thank you.

[sungam3r]

Another vote for this feature.

[SteppeHunter]

Hi.

Having support for 32 bit is still relevant especially for efficient code running on containers or in VMs on the cloud. Reducing the memory footprint still has a significant impact on resources and cost.
Any new on this matter?

Thank you.

We have same problem. We have no microservices that need 64 bit memory at all. So 32 bit CLR for Linux needed for efficient memory consumption on big Kubernetes cluster.