[Dev] Fix host architecture to x86_64 for building arm target

Carsten Haitzler c.haitzler at samsung.com
Mon Dec 12 01:59:12 GMT 2016


On Mon, 12 Dec 2016 01:43:37 +0000
MyungJoo Ham <myungjoo.ham at samsung.com> wrote:

> >On Fri, 09 Dec 2016 05:58:22 +0000
> >윤지영 <jy910.yun at samsung.com> wrote:
> >  
> >>  
> >>  
> >> --------- Original Message ---------
> >> Sender : 하이츨러 <c.haitzler at samsung.com> Master/S/W
> >> Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 14:34 (GMT+9)
> >> Title  : Re: [Dev] Fix host architecture to x86_64 for building arm
> >> target 
> >> On Fri, 09 Dec 2016 05:28:19 +0000
> >> 윤지영 <jy910.yun at samsung.com> wrote:
> >>    
> >> >      
> >> > > --------- Original Message ---------
> >> > > Sender : 하이츨러 <c.haitzler at samsung.com> Master/S/W
> >> > > Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 12:08 (GMT+9)
> >> > > Title  : Re: [Dev] Fix host architecture to x86_64 for
> >> > > building arm target 
> >> > > On Fri, 09 Dec 2016 03:05:54 +0000
> >> > > 윤지영 <jy910.yun at samsung.com> wrote:
> >> > >        
> >> > > >  
> >> > > > Dear all,
> >> > > >       
> >> > > > > is it x86-64 that it needs or just a large memory address
> >> > > > > space (like chromium for example)?        
> >> > > > 
> >> > > > .NET is a little different.
> >> > > > At present, .NET only provides toolchains for x86-64. To
> >> > > > create arm binaries for .NET runtime and libraries, x86-64
> >> > > > libraries are needed in the GBS arm environment. To do so,
> >> > > > we use the qemu-accel package for x86_64, which installs the
> >> > > > libraries for x86-64 in /emul/ directory on arm GBS
> >> > > > environment and .NET toolchains link them.
> >> > > > 
> >> > > > We have tried to support .NET toolchains for arm. However,
> >> > > > even if we have .NET toolchains for arm, there is a high
> >> > > > possibility of using x86-64 toolchain as usual due to build
> >> > > > speed issue. In the light of our experience, it took more
> >> > > > than 24 hours to build the runtime, but it did not
> >> > > > succeed.      
> >> > >  
> >> > > ok but it isn't something specific like "it uses x86-64
> >> > > assembly and thus only works on x86-64". it's just a question
> >> > > of building the toolchain for arm or i586 or mips or any other
> >> > > architecture - right?      
> >> > 
> >> > More specifically, it does not create a toolchain for arm.
> >> > The toolchain runs on x86_64 called 'dotnet' creates arm
> >> > binaries and C# managed dlls.    
> >>    
> >> > but can the toolchain be built for arm? can it run on arm? does
> >> > it ONLY run on x86-64 - why only on x86-64 if so?    
> >> 
> >> At present, the toolchain for arm is not available and we are
> >> trying to support it as soon as possible. If it is provided, it
> >> can, of course, run on arm. However, even though the toolchain for
> >> arm is provided, we are considering using the toolchain for x86_64
> >> for build acceleration.  
> >
> >ok. so i'm curious... why is it "not provided" what needs to be done
> >to make it work? is this like luajit where it has architecture
> >specific assembly for it's core and so needs to be ported for each
> >architecture?
> >  
> 
> In order to build dotnet-core runtime (coreclr) armv7l/Linux with
> crosscompilers, the building environment should be x86-64. x86-32
> simply cannot support it because dotnet-core runtime does not support
> x86-32; you need to run dotnet-core itself to build dotnet-core (to
> build mscorlib.dll for target arch)

this is what i don't get. MONO (which is what xamarin was actually
build on top of) runs on armv7. even armv6. it also has run on i586 for
years and years. dotnetcore if it requires a jit to run (a CLR
jit) ..then there already is one - MONO has had it for years.

or is this the difference between MONO and microsoft's own dotnet-core
which is far more limited in platform support? this is a specific
limitation of microsft's code? i am unfamiliar with what EXACTLY
dotnet-core is but i suspect it's microsoft's own implementation.

but i DO know MONO has built for and run on a massive range of
architectures for years and years... even back when x86_64 was very new
and shiny and it had to support i586 as that was the vast majority of
the PC market.

> You may try to build dotnet-core armv7l/Linux at ARM(armv7l);
> however, the dotnet toolchain for armv7l is not released officially
> via the official sites (are they releasing ARM/Linux officially these
> days?), which means that you cannot reuse the toolchain release infra
> and the default building scripts, which automatically updates
> dotnet-core toolchains via the Internet. You need to rebuild the
> whole toolchain sets for your toolchain sets. (build dotnet-core
> ARM/Linux to build dotnet-core ARM/Linux for every major updates in
> dotnet-core ARM/Linux). Besides, building dotnet-core ARM/Linux at
> armv7l-qemu at x86-64 takes x10 times of building dotnet-core
> ARM/Linux directly at x86-64 (with crosscompiling toolchains). It's
> 10 min vs 100 min in my desktop.

so why not use MONO? :) it almost sounds like we've chosen a far more
limiting codebase than a far better supported one. especially for our
needs of supporting multiple architectures...

> With the default configurations of qemu accelerations, OBS/GBS uses
> x86-32 for armv7l, which is not suitable for dotnet-core armv7l.
> Thus, in order to reuse MS's toolchain infrastructures and in order
> to accelerate building dotnet-core, they might want to use x86-64 for
> dotnet-core armv7l.
> 
> 
> Cheers,
> MyungJoo
> 
> ps. I'd been away from dotnet-core for a while. So, JY, please
> correct me if things have been changed. (e.g., did they start
> supporting x86-32 or so..)



More information about the Dev mailing list