Re: Building a native version of Linaro GCC in Ubuntu

2014-03-13 Thread Zhenqiang Chen
On 13 March 2014 07:42, Felipe Rocha da Rosa  wrote:
>
>> On 12 March 2014 09:57, Renato Golin  wrote:
>> > On 11 March 2014 23:47, Felipe Rocha da Rosa 
>> > wrote:
>> >> I'm trying to build the native compiler to a arm a9 using this
>> >> tutorial,
>> >> https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative.
>> >> However, I need to compile in a x86_64 platform ubuntu,
>> >> like this --target=arm-unknown-eabi --build=i686-pc-linux-gnu
>> >> --host=arm-unknown-eabi, but without success.
>> >
>> > It's odd that you have to set --host as ARM, since your host is x86_64.
>> >
>> > Also, GCC might be different, but arm-unknown-eabi is a bare metal
>> > toolchain, not a linux one, maybe that's another source of problems.
>> > Try arm-linux-gnueabi for soft-float and arm-linux-gnueabihf for
>> > hard-float.
>> >
>>
>> IIUC, what you are trying to do is called "Canadian Cross" build,
>> which involves to use a cross-compiler:
>> - you'll use an x86_64 compiler to build a cross-compiler, running on
>> x86_64 and producing code for ARM.
>> - then you'll use this cross-compiler to cross-build the native-ARM
>> compiler.
>>
>> I believe there is some documentation in GCC about Canadian Cross
>> builds, and I think cbuild2 supports such builds too.
>>
>> Christophe.
>
> Let's me explain, I want to compile that will be hosted and working  in a
> ARM  A9 Linux producing ARM binary (cross-native), but I need to create this
> compiler in my machine ubuntu x86_x64. Canadian cross, I think is when the
> three are different archs

But the process is similar.

Please try my hack based on Linaro crosstool-ng Canadian windows build.

(1) wget 
http://cbuild.validation.linaro.org/snapshots/crosstool-ng-linaro-1.13.1-4.8-2014.02.tar.bz2
(2) tar -xf crosstool-ng-linaro-1.13.1-4.8-2014.02.tar.bz2
(3) cd crosstool-ng-linaro-1.13.1-4.8-2014.02
(4) patch -p1 < hack.patch (attached. It changes HOST from
i586-mingw32msvc to arm-linux-gnueabi)
(5) make -f contrib/linaro/build.mk TARGETS=arm-linux-gnueabi

Please ignore the fails at the end to package windows staffs. And you
will get a toolchain at

./builds/arm-linux-gnueabi-win32/install

To build your gcc,
(1) Replace the gcc-linaro-4.8-2014.02 at
./builds/arm-linux-gnueabi-win32/.build/src
(2) Remove builds/stamp/arm-linux-gnueabi-win32-build
(3) make -f contrib/linaro/build.mk TARGETS=arm-linux-gnueabi

Good luck!

-Zhenqiang

> I 'm compiling now this  ../configure   --target=arm-none-linux-gnueabi
> --build=x86_64-linux-gnu  --host=arm-none-linux-gnueabi,
>
> Thank you.
>
>
>
>
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
>
diff -aru crosstool-ng-linaro-1.13.1-4.8-2014.02/contrib/linaro/build.mk modified/contrib/linaro/build.mk
--- crosstool-ng-linaro-1.13.1-4.8-2014.02/contrib/linaro/build.mk	2014-02-20 18:16:14.0 +0800
+++ modified/contrib/linaro/build.mk	2014-03-13 09:12:39.261004793 +0800
@@ -321,7 +321,6 @@
 		-exec $(FINAL)/bin/*-objcopy $(SECTIONS) {} \;
 
 # Override in local.mk to skip using the LSB compilers
-USE_LSBCC ?= CT_BUILD_USE_LSBCC=y
 
 # Settings to add just for Linux
 LINUX_ADD = \
@@ -330,7 +329,7 @@
 # Settings to add just for win32
 WIN32_ADD = \
 	CT_CANADIAN=y \
-	CT_HOST=\"i586-mingw32msvc\" \
+	CT_HOST=\"arm-linux-gnueabi\" \
 	CT_BINUTILS_GOLD_THREADS=n
 
 WIN32_REMOVE = \
diff -aru crosstool-ng-linaro-1.13.1-4.8-2014.02/samples/linaro-arm-linux-gnueabi/crosstool.config modified/samples/linaro-arm-linux-gnueabi/crosstool.config
--- crosstool-ng-linaro-1.13.1-4.8-2014.02/samples/linaro-arm-linux-gnueabi/crosstool.config	2014-02-20 18:16:14.0 +0800
+++ modified/samples/linaro-arm-linux-gnueabi/crosstool.config	2014-03-13 09:17:10.333505006 +0800
@@ -1,11 +1,10 @@
 #
 # Automatically generated make config: don't edit
-# crosstool-NG linaro-1.13.1+bzr2559 Configuration
-# Fri Apr 26 16:32:16 2013
+# crosstool-NG linaro-1.13.1-4.8-2014.02 Configuration
+# Thu Mar 13 09:16:54 2014
 #
 CT_CONFIGURE_has_xzutils=y
 CT_CONFIGURE_has_cvs=y
-CT_CONFIGURE_has_svn=y
 CT_MODULES=y
 
 #
@@ -115,7 +114,7 @@
 CT_ARCH_LE=y
 CT_ARCH_32=y
 CT_ARCH_BITNESS=32
-CT_ARCH_FLOAT_HW=y
+# CT_ARCH_FLOAT_HW is not set
 # CT_ARCH_FLOAT_SW is not set
 CT_TARGET_CFLAGS="-g -O2"
 CT_TARGET_LDFLAGS=""
@@ -173,9 +172,7 @@
 #
 CT_FORCE_SYSROOT=y
 CT_USE_SYSROOT=y
-CT_PREBUILT_SYSROOT=y
-CT_PREBUILT_NAME="linaro-prebuilt-sysroot-2013.10"
-CT_PREBUILT_BASE_URL="http://launchpad.net/linaro-toolchain-binaries/support/01/+download";
+# CT_PREBUILT_SYSROOT is not set
 CT_SYSROOT_NAME="libc"
 CT_SYSROOT_DIR_PREFIX=""
 # CT_STATIC_TOOLCHAIN is not set
@@ -210,20 +207,19 @@
 # Misc options
 #
 CT_TOOLCHAIN_ENABLE_NLS=y
-CT_TOOLCHAIN_ENABLE_MULTILIB=y
+# CT_TOOLCHAIN_ENABLE_MULTILIB is not set
 
 #
 # Operating System
 #
 CT_KERNEL_SUPPORTS_SHARED_LIBS=y
 CT_KERNEL="linux"
+CT_KERNEL_VERSION="3.1.1"
 # CT_KERNEL_bare_metal is not set
 CT_KERNE

Re: linking AArch64 ELF image with aarch64-linux-gnu-ld yields RELASZ = 0

2014-03-13 Thread Will Newton
On 11 March 2014 20:51, Claudio Fontana  wrote:

Hi Claudio,

> I am building an ELF image using aarch64-linux-gnu-ld from linaro:
>
> GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.02 - Linaro GCC 2014.02)
> 2.24.0.20131220
>
> I am linking in the libstc++.a, which contains in particular a GOT
> entry for __gthread_active_ptr that is of interest to me, pointing to
> __pthread_key_create, used for detecting pthread support for
> std::thread,
>
> and while I get the relocations for the GOT itself in a .rela.dyn
> section, and a nice pointer to it from the dynamic section (RELA), the
> dynamic RELASZ entry contains zero:
>
> Here is the comparison of the Dynamic section (note RELASZ) with the
> following .rela.dyn relocations:
>
> loader.elf: file format elf64-littleaarch64
> loader.elf
> architecture: aarch64, flags 0x0112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x400b
>
> Program Header:
> LOAD off0x vaddr 0x4009 paddr
> 0x4009 align 2**16
>  filesz 0x00407084 memsz 0x004aa504 flags rwx
>  TLS off0x00407080 vaddr 0x40497080 paddr
> 0x40497080 align 2**3
>  filesz 0x0004 memsz 0x0580 flags rw-
>  DYNAMIC off0x1000 vaddr 0x40091000 paddr
> 0x40091000 align 2**3
>  filesz 0x0120 memsz 0x0120 flags rw-
> EH_FRAME off0x003ce5fc vaddr 0x4045e5fc paddr
> 0x4045e5fc align 2**2
>  filesz 0xbae4 memsz 0xbae4 flags r--
> NOTE off0x vaddr 0x paddr
> 0x align 2**3
>  filesz 0x memsz 0x flags ---
>
> Dynamic Section:
>   NEEDED   dummy-shlib.so
>   INIT_ARRAY   0x404841b8
>   INIT_ARRAYSZ 0x0330
>   HASH 0x4044bd58
>   STRTAB   0x403e3320
>   SYMTAB   0x403a4110
>   STRSZ0x00068a33
>   SYMENT   0x0018
>   DEBUG0x
>   RELA 0x404780c0
>   RELASZ   0x
>   RELAENT  0x0018
> private flags = 0:
>
> ...
>  10 .rela.dyn 2058  404780c0  404780c0  003e80c0  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
> ...
> and now the .rela.dyn.relocations from aarch64-linux-gnu-readelf -r
> loader.elf :
>
> Relocation section '.rela.dyn' at offset 0x3e80c0 contains 345 entries:
>   Offset  Info   Type   Sym. ValueSym. Name + 
> Addend
> 404832d0  002b0401 R_AARCH64_GLOB_DA 405339c8
> _ZNSt8time_getIwSt19is + 0
> 404832d8  00440401 R_AARCH64_GLOB_DA 4047e450
> _ZTISt7codecvtIcc11__m + 0
> 404832e0  004b0401 R_AARCH64_GLOB_DA 405338c8
> _ZGVNSt8numpunctIcE2id + 0
> 404832e8  00580401 R_AARCH64_GLOB_DA 4047c460
> _ZTISt8messagesIcE + 0
> 404832f0  00620401 R_AARCH64_GLOB_DA 4047df40
> _ZTVSt9strstream + 0
> 404832f8  00720401 R_AARCH64_GLOB_DA 402870dc
> _ZNSt17bad_function_ca + 0
> 40483300  00850401 R_AARCH64_GLOB_DA 40534e58
> _ZGVN9__gnu_cxx16bitma + 0
> 40483310  00c30401 R_AARCH64_GLOB_DA 40533a18
> _ZNSt6locale2id11_S_re + 0
> 40483318  00dd0401 R_AARCH64_GLOB_DA 4047c160
> _ZTISt5ctypeIwE + 0
> 40483320  00ea0401 R_AARCH64_GLOB_DA 40534e18
> _ZZN9__gnu_cxx9free_li + 0
> 40483328  01170401 R_AARCH64_GLOB_DA 40533968
> _ZGVNSt8time_getIwSt19 + 0
> 40483330  01350401 R_AARCH64_GLOB_DA 4047cfd8
> _ZTISt7num_getIwSt19is + 0
> 40483338  01730401 R_AARCH64_GLOB_DA 4021d51c
> __pthread_key_create + 0
>
> ...
>
> ^^...note the __pthread_key_create relocation I am interested in...
>
> I would expect the RELASZ in the dynamic section to be 0x2058 instead of 0.
>
> Any tips to what could be wrong?

I can't see any obvious way this could happen from looking at the
linker code. Do you have a method for reproducing the problem you
could share? Or could you send me the binary?

Thanks,


-- 
Will Newton
Toolchain Working Group, Linaro

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain