<p dir="ltr"><br>
2015-3-17 21:30  "Gustavo Zacarias" <<a href="mailto:gustavo@zacarias.com.ar">gustavo@zacarias.com.ar</a>> wrote:<br>
><br>
> On 03/16/2015 07:00 AM, Zhang Jian(Bamvor) wrote:<br>
> > LP64 is the default ABI on arm64(Implies -mabi=lp64 while compiling), and the<br>
> > kernel remains in LP64 no matter ILP32 enables or not.<br>
> ><br>
> > These series patches introduce the big endian support in aarch64 and then add<br>
> > ILP32 special filename and menuconfig step by step.<br>
> ><br>
> > The test of build is based on linaro kernel [1] and toolchain built by linaro<br>
> > ABE environment[2].<br>
> ><br>
> > This is my first time I try to contribute the buildroot, feedback is very<br>
> > appreciated. Sorry if there are some coding style issues.<br>
><br>
> Hi.<br>
> A couple of issues i've discovered with this patchset are:<br>
><br>
Hi, Gustavo</p>
<p dir="ltr">> 1) You're using -mabi unconditionally.<br>
> Current default gcc is 4.8.x which doesn't understand -mabi for aarch64.<br>
Yes. <br>
><br>
> 2) You're not taking care of the internal toolchain backend for ILP32.<br>
> Currently we default to gcc 4.8.x which doesn't handle ilp32 at all<br>
> hence errors out for aarch64 in that configuration (doesn't understand<br>
> -mabi, point 1).<br>
> The proper action would be to lock down available versions in<br>
> package/gcc/Config.in.host via "depends on !BR2_AARCH64_ILP32"<br>
> (basically just for 4.8.x since previous versions are already locked out<br>
> for aarch64 in general).<br>
I will do it in next version.<br>
> This will only fix the ILP32 problem, doesn't help for -mabi=lp64 though<br>
> (point 1).<br>
Well, do you mean I should handle -mabi=lp64 as well? It is the default api in aarch64 gcc 4.9.x. It may be useful when build the kernel.<br>
> 3) ILP32 little endian doesn't build with gcc 4.9.x/binutils 2.25/glibc<br>
> 2.20: it results in an internal compiler error while building glibc, so<br>
> very likely gcc's fault. This should be handled as well, by fixing it or<br>
> disabling the internal toolchain backend for this combination.<br>
I guess linaro has the patch in it while I hope I could deal with it after the external toolchain patches is accept. Do you comfortable with only external toolchain support at this time?<br>
><br>
> 3) Big endian support is broken for the internal toolchain.<br>
> The glibc package isn't enabled for aarch64 BE, so basically it builds a<br>
> toolchain without a libc, not nice.<br>
> Fix in toolchain/toolchain-buildroot/Config.in - add appropiate<br>
> BR2_aarch64_be depends.<br>
Ok,  i will do it.<br>
><br>
> 4) We don't know/have any external toolchains to test this.<br>
> Suggestions? :)<br>
We could test it with linaro gcc built from linaro abe system.<br>
><br>
> 5) You're not setting KERNEL_ARCH appropiately for big endian, right now<br>
> the regex is: -e s/aarch64/arm64/<br>
> It should be: -e s/aarch64.*/arm64/<br>
> Otherwise we end up with KERNEL_ARCH being arm64_be which obviously<br>
> fails badly, not only for kernel builds, but also for internal<br>
> toolchains builds (headers), possibly some packages and linux extensions.<br>
> Fix in top Makefile.<br>
Ok. <br>
><br>
> There are probably other details missing, these are the quick/big ones i<br>
> could see.<br>
maybe I should add RFC for my next verion of patches.</p>
<p dir="ltr">regards</p>
<p dir="ltr">bamvor<br>
><br>
> Regards.<br>
> _______________________________________________<br>
> buildroot mailing list<br>
> <a href="mailto:buildroot@busybox.net">buildroot@busybox.net</a><br>
> <a href="http://lists.busybox.net/mailman/listinfo/buildroot">http://lists.busybox.net/mailman/listinfo/buildroot</a><br>
</p>