| Message ID | 20180704155605.1892-1-christophe.lyon@st.com |
|---|---|
| Headers | show |
| Series | FDPIC ABI for ARM | expand |
Hello Christophe, Thanks for this work on ARM FDPIC support. I'm starting to look at integrating this in Buildroot. However, I have one question below. On Wed, 4 Jul 2018 17:55:13 +0200, Christophe Lyon wrote: > On ARM, the FDPIC register is r9 [1], and the target name is > arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another The arm-uclinuxfdpiceabi tuple looks weird. Indeed, most architecture tuples have the form: <arch>-<vendor>-<os>-<libc/abi> Where the "vendor" part is optional. However, with arm-uclinuxfdpiceabi there is no dash separating the OS ("uclinux") from the libc/abi part of the tuple. Is this expected ? Best regards, Thomas
On Thu, 5 Jul 2018 at 09:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Christophe, > > Thanks for this work on ARM FDPIC support. I'm starting to look at > integrating this in Buildroot. However, I have one question below. > > On Wed, 4 Jul 2018 17:55:13 +0200, Christophe Lyon wrote: > > > On ARM, the FDPIC register is r9 [1], and the target name is > > arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another > > The arm-uclinuxfdpiceabi tuple looks weird. Indeed, most architecture > tuples have the form: > > <arch>-<vendor>-<os>-<libc/abi> > > Where the "vendor" part is optional. > > However, with arm-uclinuxfdpiceabi there is no dash separating the OS > ("uclinux") from the libc/abi part of the tuple. > > Is this expected ? > Yes, this was discussed when I submitted the binutils patches: https://sourceware.org/ml/binutils/2018-03/msg00324.html > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com
Hello, On Thu, 5 Jul 2018 10:51:01 +0200, Christophe Lyon wrote: > > However, with arm-uclinuxfdpiceabi there is no dash separating the OS > > ("uclinux") from the libc/abi part of the tuple. > > > > Is this expected ? > > > Yes, this was discussed when I submitted the binutils patches: > https://sourceware.org/ml/binutils/2018-03/msg00324.html It seems like a strange choice. Why not arm-uclinux-fdpiceabi ? Anyway, I guess this is now fixed in stone :) Also, side question: do you support both EABI and EABIhf, i.e is arm-uclinuxfdpiceabihf supported ? Best regards, Thomas
On Thu, 5 Jul 2018 at 10:57, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Thu, 5 Jul 2018 10:51:01 +0200, Christophe Lyon wrote: > > > > However, with arm-uclinuxfdpiceabi there is no dash separating the OS > > > ("uclinux") from the libc/abi part of the tuple. > > > > > > Is this expected ? > > > > > Yes, this was discussed when I submitted the binutils patches: > > https://sourceware.org/ml/binutils/2018-03/msg00324.html > > It seems like a strange choice. Why not arm-uclinux-fdpiceabi ? Anyway, I don't know, I trusted Joseph :) > I guess this is now fixed in stone :) Probably not, there are no official releases yet (but I think the next binutils one will happen very soon) > Also, side question: do you support both EABI and EABIhf, i.e is > arm-uclinuxfdpiceabihf supported ? I didn't test the hf version. But given the nature of the changes, I think it should work. Are you worried about something in particular? > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com
Hi, I'd like to ping the whole series. For those anxious about Cortex-M support, I'd prefer to have the current patch series merged, and then add the missing parts for Cortex-M: I have a simple patch to enable the uclibc-ng build for such a target, but then there are further problems with binutils and GCC. So for me it would be much more convenient to have Cortex-A/Cortex-R support merged, so that I can focus later on smaller improvements. Thanks, Christophe On Wed, 4 Jul 2018 at 17:56, Christophe Lyon <christophe.lyon@st.com> wrote: > > Hello, > > This patch series implements the uClibc-ng contribution of the FDPIC > ABI for ARM targets. > > This ABI enables to run Linux on ARM MMU-less cores and supports > shared libraries to reduce the memory footprint. > > Without MMU, text and data segments relative distances are different > from one process to another, hence the need for a dedicated FDPIC > register holding the start address of the data segment. One of the > side effects is that function pointers require two words to be > represented: the address of the code, and the data segment start > address. These two words are designated as "Function Descriptor", > hence the "FD PIC" name. > > On ARM, the FDPIC register is r9 [1], and the target name is > arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another > ABI and the BFLAT file format; it does not support code sharing. > > This work was developed some time ago by STMicroelectronics, and was > presented during Linaro Connect SFO15 (September 2015). You can watch > the discussion and read the slides [2]. > This presentation was related to the toolchain published on github [3], > which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1 > and qemu-2.3.0, and for which pre-built binaries are available [3]. > > The ABI itself is described in details in [1]. > > Our Linux kernel patches have been updated and committed by Nicolas > Pitre (Linaro) in July 2017. They are required so that the loader is > able to handle this new file type. Indeed, the ELF files are tagged > with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as > well as the new relocations involved. > > The binutils and QEMU patch series have been merged recently. [4][5] > > The GCC patch series has been submitted and is under discussion. [6] > > This patch series consists in the original uClibc-based patches, which > I have rebased and updated for uClibc-ng. Most of them are strictly > related to FDPIC on ARM, while a few others address generic issues. > > Are the uClibc-ng patches OK for inclusion in master? > > Thanks, > > Christophe. > > > [1] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt > [2] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ > [3] https://github.com/mickael-guene/fdpic_manifest > [4] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f1ac0afe481e83c9a33f247b81fa7de789edc4d9 > [5] https://git.qemu.org/?p=qemu.git;a=commit;h=e8fa72957419c11984608062c7dcb204a6003a06 > [6] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01439.html > > Christophe Lyon (32): > [ARM][FDPIC] Allow to select FDPIC ELF for arm architecture > [FDPIC] rtld: Do not protect RELRO segments when we don't use an MMU. > [ARM][FDPIC] rtld: Add #if defined (__FDPIC__) > [ARM][FDPIC] rtld: Add FDPIC code for arm > [ARM][FDPIC] rtld: Avoid FUNCDESC relocation on _start > [ARM][FDPIC] rtld: Add startup code > [ARM] Fix bug in _dl_pread when using pread64 syscall > [ARM][FDPIC] Add application startup code for FDPIC > [ARM][FDPIC] Add runtime support needed for C++ exceptions > [ARM][FDPIC] Allow to generate PIE 'static' binary > [ARM][FDPIC] rtld: Add lazy binding support > [ARM][FDPIC] TLS: fix relocation computation > [ARM][FDPIC] rtld: Compile with -fno-unwind-tables > -fno-asynchronous-unwind-tables > [ARM][FDPIC] arm/clone.S: Fix threading support > [ARM][FDPIC] enable NPTL on TARGET_arm > [ARM][FDPIC] rtld: Use ELF_RTYPE_CLASS_DLSYM > [FDPIC] rtld: Initialize _dl_error_catch_tsd without FUNCDESC > relocation > [FDPIC] nptl: disable mprotect usage in stack protection > [FDPIC] nptl: Disable fork and atfork on MMU-less systems. > [FDPIC] nptl: Do not use madvise > [ARM][FDPIC] nptl: Use linker-defined symbol to find start of .tdata > section. > [FDPIC] nptl: Allow sem_open to work on MMU-less systems > [FDPIC] nptl: Add pthread_mutex_getprioceiling and > pthread_mutex_setprioceiling support > [FDPIC] nptl: Use vfork on MMU-less for system() > nptl: Clear TLS area for static binaries. > [FDPIC] nptl: Replace sbrk with mmap > nptl threads: Fix bug in using a weak variable. > Fix htab_delete loop counter > isnan: Add isnan weak alias to __isnan > mbtowc: Fix non compliant behavior for end of string > Fix shm_open posix compliance error code > [ARM] rtld: Avoid crash on R_ARM_NONE relocation > > extra/Configs/Config.in | 2 +- > extra/Configs/Config.in.arch | 2 +- > include/elf.h | 2 + > include/link.h | 6 +- > ldso/include/dl-elf.h | 2 +- > ldso/include/dl-hash.h | 2 +- > ldso/include/dl-string.h | 3 +- > ldso/include/dl-syscall.h | 13 +- > ldso/include/inline-hashtab.h | 2 +- > ldso/ldso/Makefile.in | 2 - > ldso/ldso/arm/dl-inlines.h | 1 + > ldso/ldso/arm/dl-startup.h | 112 +++++++++++++- > ldso/ldso/arm/dl-sysdep.h | 63 ++++++-- > ldso/ldso/arm/elfinterp.c | 166 +++++++++++++++++---- > ldso/ldso/arm/resolve.S | 23 +++ > ldso/ldso/dl-elf.c | 6 +- > ldso/ldso/dl-hash.c | 4 +- > ldso/ldso/dl-tls.c | 1 + > ldso/ldso/fdpic/dl-inlines.h | 2 + > ldso/ldso/fdpic/dl-sysdep.h | 2 +- > ldso/ldso/ldso.c | 23 ++- > libc/misc/elf/dl-iterate-phdr.c | 2 +- > libc/misc/internals/__uClibc_main.c | 47 +++++- > libc/stdlib/stdlib.c | 6 +- > libc/stdlib/system.c | 5 + > libc/sysdeps/linux/arm/Makefile.arch | 2 +- > libc/sysdeps/linux/arm/bits/elf-fdpic.h | 114 ++++++++++++++ > libc/sysdeps/linux/arm/clone.S | 12 ++ > libc/sysdeps/linux/arm/crt1.S | 66 ++++++++ > libc/sysdeps/linux/arm/crtreloc.c | 144 ++++++++++++++++++ > libc/sysdeps/linux/arm/find_exidx.c | 38 +++++ > libc/sysdeps/linux/arm/find_got.c | 72 +++++++++ > libm/s_isnan.c | 1 + > libpthread/nptl/Makefile.in | 1 - > libpthread/nptl/allocatestack.c | 6 + > libpthread/nptl/linux_fsinfo.h | 5 +- > libpthread/nptl/pthread_create.c | 4 + > libpthread/nptl/sem_open.c | 8 +- > libpthread/nptl/sysdeps/generic/libc-tls.c | 27 +++- > libpthread/nptl/sysdeps/unix/sysv/linux/fork.c | 3 + > .../sysdeps/unix/sysv/linux/libc_pthread_init.c | 4 + > .../nptl/sysdeps/unix/sysv/linux/register-atfork.c | 14 +- > .../sysdeps/unix/sysv/linux/unregister-atfork.c | 10 +- > librt/shm.c | 3 + > 44 files changed, 958 insertions(+), 75 deletions(-) > create mode 100644 ldso/ldso/arm/dl-inlines.h > create mode 100644 libc/sysdeps/linux/arm/bits/elf-fdpic.h > create mode 100644 libc/sysdeps/linux/arm/crtreloc.c > create mode 100644 libc/sysdeps/linux/arm/find_got.c > > -- > 2.6.3 >
Hi Christophe, i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. best regards Waldemar > Am 13.07.2018 um 17:43 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > > Hi, > > I'd like to ping the whole series. > > For those anxious about Cortex-M support, I'd prefer to have the > current patch series merged, and then add the missing parts for > Cortex-M: I have a simple patch to enable the uclibc-ng build for such > a target, but then there are further problems with binutils and GCC. > So for me it would be much more convenient to have Cortex-A/Cortex-R > support merged, so that I can focus later on smaller improvements. > > Thanks, > > Christophe > > >> On Wed, 4 Jul 2018 at 17:56, Christophe Lyon <christophe.lyon@st.com> wrote: >> >> Hello, >> >> This patch series implements the uClibc-ng contribution of the FDPIC >> ABI for ARM targets. >> >> This ABI enables to run Linux on ARM MMU-less cores and supports >> shared libraries to reduce the memory footprint. >> >> Without MMU, text and data segments relative distances are different >> from one process to another, hence the need for a dedicated FDPIC >> register holding the start address of the data segment. One of the >> side effects is that function pointers require two words to be >> represented: the address of the code, and the data segment start >> address. These two words are designated as "Function Descriptor", >> hence the "FD PIC" name. >> >> On ARM, the FDPIC register is r9 [1], and the target name is >> arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another >> ABI and the BFLAT file format; it does not support code sharing. >> >> This work was developed some time ago by STMicroelectronics, and was >> presented during Linaro Connect SFO15 (September 2015). You can watch >> the discussion and read the slides [2]. >> This presentation was related to the toolchain published on github [3], >> which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1 >> and qemu-2.3.0, and for which pre-built binaries are available [3]. >> >> The ABI itself is described in details in [1]. >> >> Our Linux kernel patches have been updated and committed by Nicolas >> Pitre (Linaro) in July 2017. They are required so that the loader is >> able to handle this new file type. Indeed, the ELF files are tagged >> with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as >> well as the new relocations involved. >> >> The binutils and QEMU patch series have been merged recently. [4][5] >> >> The GCC patch series has been submitted and is under discussion. [6] >> >> This patch series consists in the original uClibc-based patches, which >> I have rebased and updated for uClibc-ng. Most of them are strictly >> related to FDPIC on ARM, while a few others address generic issues. >> >> Are the uClibc-ng patches OK for inclusion in master? >> >> Thanks, >> >> Christophe. >> >>
Hi Christophe, Waldemar Brodkorb wrote, > Hi Christophe, > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > ARM v5 soft eabi arm mode fails to compile, see the attached error log. You can check with embedded-test.sh if you like. Any idea? All patches appliend on top of master, best regards Waldemar ---> Linux 4.9.0-6-amd64 for build detected. ---> checking if curl is installed.. found ---> checking if sha256sum is installed.. found ---> checking if cc is installed.. found ---> checking if c++ is installed.. found ---> checking if gmake is installed.. not found ---> checking if make is installed.. found ---> checking if it is GNU make.. yes ---> checking if bash is installed.. found ---> checking if it is bash 4.x.. yes ---> checking if strings is installed.. found ---> checking if perl is installed.. found ---> checking if gzip is installed.. found ---> checking if git is installed.. found ---> checking if compiler is working.. okay ---> checking if zlib is installed.. found ---> checking if bc is installed.. not found ---> checking if bison is installed.. found ---> checking if bzip2 is installed.. found ---> checking if file is installed.. found ---> checking if flex is installed.. found ---> checking if mksh is installed.. found ---> checking if patch is installed.. found ---> checking if xargs is installed.. found ---> checking if find is installed.. found ---> checking if grep is installed.. found ---> checking if gawk is installed.. found ---> checking if sed is installed.. found ---> checking if cpio is installed.. found ---> checking if xz is installed.. found Build started on Wed Jul 18 09:28:04 CEST 2018 + ulimit -dH + __limit=unlimited + test -n unlimited + ulimit -Sd unlimited + ulimit -n 1024 + make -f /home/wbx/embedded-test/openadk/mk/build.mk ADK_VERBOSE=1 all /usr/bin/make -f mk/build.mk package/hostcompile toolchain/final target/config-prepare target/compile package_clean package/compile root_clean package/install target/install package_index /usr/bin/make -C package hostcompile : "package/adk-helper-host.. " /usr/bin/make -C adk-helper hostpackage : " done" : : "package/m4-host.. " /usr/bin/make -C m4 hostpackage : " done" : : "package/autoconf-host.. " /usr/bin/make -C autoconf hostpackage : " done" : : "package/bison-host.. " /usr/bin/make -C bison hostpackage : " done" : : "package/patch-host.. " /usr/bin/make -C patch hostpackage : " done" : : "package/automake-host.. " /usr/bin/make -C automake hostpackage : " done" : : "package/libtool-host.. " /usr/bin/make -C libtool hostpackage : " done" : : "package/flex-host.. " /usr/bin/make -C flex hostpackage : " done" : : "package/bc-host.. " /usr/bin/make -C bc hostpackage : " done" : : "package/pkgconf-host.. " /usr/bin/make -C pkgconf hostpackage : " done" : /usr/bin/make -C toolchain final : "toolchain/binutils/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/binutils/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/binutils/compile.. " make[5]: Nothing to be done for 'compile'. : " done" : : "toolchain/binutils/install.. " make[5]: Nothing to be done for 'install'. : " done" : : "toolchain/gmp/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/gmp/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/gmp/compile.. " make[5]: Nothing to be done for 'compile'. : " done" : : "toolchain/gmp/install.. " make[5]: Nothing to be done for 'install'. : " done" : : "toolchain/mpfr/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/mpfr/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/mpfr/compile.. " make[5]: Nothing to be done for 'compile'. : " done" : : "toolchain/mpfr/install.. " make[5]: Nothing to be done for 'install'. : " done" : : "toolchain/mpc/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/mpc/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/mpc/compile.. " make[5]: Nothing to be done for 'compile'. : " done" : : "toolchain/mpc/install.. " make[5]: Nothing to be done for 'install'. : " done" : : "toolchain/gcc/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/gcc/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/linux-headers/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/linux-headers/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/uclibc-ng/prepare.. " make[5]: Nothing to be done for 'prepare'. : " done" : : "toolchain/uclibc-ng/configure.. " make[5]: Nothing to be done for 'configure'. : " done" : : "toolchain/uclibc-ng/compile.. " PATH='/home/wbx/embedded-test/openadk/scripts:/home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/bin:/home/wbx/embedded-test/openadk/host_x86_64-linux-gnu/usr/bin:/home/wbx/embedded-test/openadk/host_x86_64-linux-gnu/usr/sbin:/home/wbx/embedded-test/openadk/host_x86_64-linux-gnu/bin:/home/wbx/bin:/home/wbx/qemu/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games' /usr/bin/make -j16 -C /home/wbx/embedded-test/openadk/toolchain_build_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/w-uClibc-ng-1.0.30-1/uClibc-ng-1.0.30 \ ARCH="arm" \ CROSS_COMPILE="/home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/bin/arm-openadk-linux-uclibceabi-" \ HOSTCC="cc" \ PREFIX=/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm \ DEVEL_PREFIX=/usr/ \ RUNTIME_PREFIX=/ \ UCLIBC_EXTRA_CFLAGS="-fwrapv -fno-ident -mcpu=arm926ej-s -mfloat-abi=soft -Os -pipe -fomit-frame-pointer -marm -Wa,-mfloat-abi=soft" \ UCLIBC_EXTRA_LDFLAGS="-L/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/lib -L/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/lib -Wl,-O1 -Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link -Wl,/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/lib" \ VERBOSE=1 \ all /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/bin/arm-openadk-linux-uclibceabi-gcc -c ldso/ldso/ldso.c -o ldso/ldso/ldso.oS -Wall -Wstrict-prototypes -Wstrict-aliasing -Wno-nonnull-compare -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -mlittle-endian -fno-stack-protector -nostdinc -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/arm -I./libc/sysdeps/linux -I./ldso/ldso/arm -I./ldso/include -I. -Os -fstrict-aliasing -fwrapv -fno-ident -mcpu=arm926ej-s -mfloat-abi=soft -Os -pipe -fomit-frame-pointer -marm -Wa,-mfloat-abi=soft -D__USE_STDIO_FUTEXES__ -DHAVE_FORCED_UNWIND -D_LIBC_REENTRANT -I./libpthread/nptl -I./libpthread/nptl -I./libpthread/nptl/sysdeps/unix/sysv/linux/arm -I./libpthread/nptl/sysdeps/arm -I./libpthread/nptl/sysdeps/arm -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits -I./libpthread/nptl/sysdeps/generic -I./libc/sysdeps/linux/common -isystem /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/lib/gcc/arm-openadk-linux-uclibceabi/7.3.0/include-fixed -isystem /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/lib/gcc/arm-openadk-linux-uclibceabi/7.3.0/include -I/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/usr/include/ -DNDEBUG -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -fno-omit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables -I./ldso/ldso/arm -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX=\"/\" -DUCLIBC_LDSO=\"ld-uClibc.so.1\" -DIN_LIB=rtld -fPIC -DSHARED -DLDSO_ELFINTERP=\"arm/elfinterp.c\" -DLDSO_MULTILIB_DIR=\"lib/\" -MT ldso/ldso/ldso.oS -MD -MP -MF ldso/ldso/.ldso.oS.dep In file included from ./include/bits/waitstatus.h:72:0, from ./include/stdlib.h:44, from ./ldso/include/ldso.h:33, from ldso/ldso/ldso.c:32: ./ldso/include/dl-syscall.h: In function '_dl_pread': ./ldso/include/dl-syscall.h:169:69: warning: right shift count >= width of type [-Wshift-count-overflow] return __syscall_pread(fd, buf, count, 0, __LONG_LONG_PAIR((offset >> 32), (offset & 0xffffffff))); ^ ./include/endian.h:52:39: note: in definition of macro '__LONG_LONG_PAIR' # define __LONG_LONG_PAIR(HI, LO) LO, HI ^~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/dl-sysdep.h: At top level: ./ldso/ldso/arm/../fdpic/dl-sysdep.h:34:33: warning: 'struct elf32_fdpic_loadaddr' declared inside parameter list will not be visible outside of this definition or declaration #define DL_LOADADDR_TYPE struct elf32_fdpic_loadaddr ^ ./ldso/ldso/arm/dl-sysdep.h:166:23: note: in expansion of macro 'DL_LOADADDR_TYPE' elf_machine_relative (DL_LOADADDR_TYPE load_off, const Elf32_Addr rel_addr, ^~~~~~~~~~~~~~~~ In file included from ./ldso/include/dl-defs.h:77:0, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/dl-sysdep.h:166:40: error: parameter 1 ('load_off') has incomplete type elf_machine_relative (DL_LOADADDR_TYPE load_off, const Elf32_Addr rel_addr, ^~~~~~~~ ./ldso/ldso/arm/dl-sysdep.h:166:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] elf_machine_relative (DL_LOADADDR_TYPE load_off, const Elf32_Addr rel_addr, ^~~~~~~~~~~~~~~~~~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-sysdep.h:34:33: warning: 'struct elf32_fdpic_loadaddr' declared inside parameter list will not be visible outside of this definition or declaration #define DL_LOADADDR_TYPE struct elf32_fdpic_loadaddr ^ ./ldso/include/dl-elf.h:131:62: note: in expansion of macro 'DL_LOADADDR_TYPE' void *debug_addr, DL_LOADADDR_TYPE load_off); ^~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-sysdep.h:34:33: warning: 'struct elf32_fdpic_loadaddr' declared inside parameter list will not be visible outside of this definition or declaration #define DL_LOADADDR_TYPE struct elf32_fdpic_loadaddr ^ ./ldso/include/dl-elf.h:135:56: note: in expansion of macro 'DL_LOADADDR_TYPE' void *debug_addr, DL_LOADADDR_TYPE load_off) ^~~~~~~~~~~~~~~~ In file included from ./ldso/include/ldso.h:55:0, from ldso/ldso/ldso.c:32: ./ldso/include/dl-elf.h:135:73: error: parameter 4 ('load_off') has incomplete type void *debug_addr, DL_LOADADDR_TYPE load_off) ^~~~~~~~ ./ldso/include/dl-elf.h:134:14: warning: function declaration isn't a prototype [-Wstrict-prototypes] unsigned int __dl_parse_dynamic_info(ElfW(Dyn) *dpnt, unsigned long dynamic_info[], ^~~~~~~~~~~~~~~~~~~~~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/include/dl-elf.h: In function '__dl_parse_dynamic_info': ./ldso/ldso/arm/../fdpic/dl-sysdep.h:37:18: warning: implicit declaration of function '__reloc_pointer'; did you mean '__select_nocancel'? [-Wimplicit-function-declaration] ((ElfW(Addr))__reloc_pointer ((void*)(ADDR), (LOADADDR).map)) ^ ./ldso/include/dl-elf.h:200:40: note: in expansion of macro 'DL_RELOC_ADDR' dynamic_info[tag] = (unsigned long) DL_RELOC_ADDR(load_off, dynamic_info[tag]); \ ^~~~~~~~~~~~~ ./ldso/include/dl-elf.h:209:3: note: in expansion of macro 'ADJUST_DYN_INFO' ADJUST_DYN_INFO(DT_HASH, load_off); ^~~~~~~~~~~~~~~ In file included from ./ldso/include/ldso.h:60:0, from ldso/ldso/ldso.c:32: ./ldso/include/dl-hash.h: At top level: ./ldso/include/dl-hash.h:43:20: error: field 'loadaddr' has incomplete type DL_LOADADDR_TYPE loadaddr; /* Base address shared object is loaded at. */ ^~~~~~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-sysdep.h:114:14: warning: 'struct elf32_fdpic_loadmap' declared inside parameter list will not be visible outside of this definition or declaration , struct elf32_fdpic_loadmap *dl_boot_progmap, Elf32_Addr dl_boot_got_pointer ^ ./ldso/include/ldso.h:180:3: note: in expansion of macro 'DL_GET_READY_TO_RUN_EXTRA_PARMS' DL_GET_READY_TO_RUN_EXTRA_PARMS); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./ldso/ldso/arm/dl-inlines.h:1:0, from ./ldso/include/ldso.h:183, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-inlines.h:15:31: warning: 'struct elf32_fdpic_loadmap' declared inside parameter list will not be visible outside of this definition or declaration struct elf32_fdpic_loadmap *map) ^~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '__dl_init_loadaddr_map': ./ldso/ldso/arm/../fdpic/dl-inlines.h:17:9: error: dereferencing pointer to incomplete type 'struct elf32_fdpic_loadmap' if (map->version != 0) { ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:25:10: error: dereferencing pointer to incomplete type 'struct elf32_fdpic_loadaddr' loadaddr->got_value = (void *)dl_boot_got_pointer; ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '__dl_init_loadaddr': ./ldso/ldso/arm/../fdpic/dl-inlines.h:47:16: error: invalid application of 'sizeof' to incomplete type 'struct elf32_fdpic_loadmap' size = sizeof(struct elf32_fdpic_loadmap) + ^~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:48:11: error: invalid application of 'sizeof' to incomplete type 'struct elf32_fdpic_loadseg' (sizeof(struct elf32_fdpic_loadseg) * count); ^~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: At top level: ./ldso/ldso/arm/../fdpic/dl-inlines.h:61:52: error: parameter 1 ('loadaddr') has incomplete type __dl_init_loadaddr_hdr(struct elf32_fdpic_loadaddr loadaddr, void *addr, ^~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:61:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] __dl_init_loadaddr_hdr(struct elf32_fdpic_loadaddr loadaddr, void *addr, ^~~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '__dl_init_loadaddr_hdr': ./ldso/ldso/arm/../fdpic/dl-inlines.h:70:9: error: dereferencing pointer to incomplete type 'struct elf32_fdpic_loadseg' segdata->addr = (Elf32_Addr)addr; ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: At top level: ./ldso/ldso/arm/../fdpic/dl-inlines.h:84:54: error: parameter 1 ('loadaddr') has incomplete type __dl_update_loadaddr_hdr(struct elf32_fdpic_loadaddr loadaddr, void *addr, ^~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:84:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] __dl_update_loadaddr_hdr(struct elf32_fdpic_loadaddr loadaddr, void *addr, ^~~~~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '__dl_update_loadaddr_hdr': ./ldso/ldso/arm/../fdpic/dl-inlines.h:99:27: error: dereferencing pointer to incomplete type 'struct elf32_fdpic_loadseg' oldaddr = (void *)segdata->addr; ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: At top level: ./ldso/ldso/arm/../fdpic/dl-inlines.h:114:49: error: parameter 1 ('loadaddr') has incomplete type __dl_loadaddr_unmap(struct elf32_fdpic_loadaddr loadaddr, ^~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:114:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] __dl_loadaddr_unmap(struct elf32_fdpic_loadaddr loadaddr, ^~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:137:60: error: parameter 2 ('loadaddr') has incomplete type __dl_addr_in_loadaddr(void *p, struct elf32_fdpic_loadaddr loadaddr) ^~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:137:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] __dl_addr_in_loadaddr(void *p, struct elf32_fdpic_loadaddr loadaddr) ^~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '__dl_addr_in_loadaddr': ./ldso/ldso/arm/../fdpic/dl-inlines.h:142:21: error: dereferencing pointer to incomplete type 'struct elf32_fdpic_loadmap' for (c = 0; c < map->nsegs; c++) ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '_dl_funcdesc_for': ./ldso/ldso/arm/../fdpic/dl-inlines.h:168:31: error: 'struct elf_resolve' has no member named 'funcdesc_ht' struct funcdesc_ht *ht = tpnt->funcdesc_ht; ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:177:7: error: 'struct elf_resolve' has no member named 'funcdesc_ht' tpnt->funcdesc_ht = ht; ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:180:8: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types] entry = htab_find_slot(ht, entry_point, 1, hash_pointer, eq_pointer); ^ ./ldso/ldso/arm/../fdpic/dl-inlines.h: In function '_dl_lookup_address': ./ldso/ldso/arm/../fdpic/dl-inlines.h:213:12: error: 'struct elf_resolve' has no member named 'funcdesc_ht' if (!rpnt->funcdesc_ht) ^~ ./ldso/ldso/arm/../fdpic/dl-inlines.h:219:32: error: 'struct elf_resolve' has no member named 'funcdesc_ht' address = htab_find_slot(rpnt->funcdesc_ht, (void *)fd->entry_point, 0, ^~ In file included from ldso/ldso/ldso.c:45:0: ldso/ldso/arm/elfinterp.c: In function '_dl_do_reloc': ldso/ldso/arm/elfinterp.c:364:53: warning: passing argument 1 of '_dl_funcdesc_for' makes pointer from integer without a cast [-Wint-conversion] reloc_value = (unsigned long) _dl_funcdesc_for(symbol_addr + reloc_value, sym_ref.tpnt->loadaddr.got_value); ^~~~~~~~~~~ In file included from ./ldso/ldso/arm/dl-inlines.h:1:0, from ./ldso/include/ldso.h:183, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-inlines.h:165:1: note: expected 'void *' but argument is of type 'long unsigned int' _dl_funcdesc_for (void *entry_point, void *got_value) ^~~~~~~~~~~~~~~~ In file included from ldso/ldso/dl-startup.c:94:0, from ldso/ldso/ldso.c:86: ./ldso/ldso/arm/dl-startup.h: At top level: ./ldso/ldso/arm/dl-startup.h:199:46: error: parameter 4 ('load_addr') has incomplete type unsigned long symbol_addr, DL_LOADADDR_TYPE load_addr, Elf32_Sym *symtab) ^~~~~~~~~ ./ldso/ldso/arm/dl-startup.h:198:6: warning: function declaration isn't a prototype [-Wstrict-prototypes] void PERFORM_BOOTSTRAP_RELOC(ELF_RELOC *rpnt, unsigned long *reloc_addr, ^~~~~~~~~~~~~~~~~~~~~~~ In file included from ldso/ldso/ldso.c:86:0: ldso/ldso/dl-startup.c: In function '_dl_start': ldso/ldso/dl-startup.c:124:19: error: storage size of 'load_addr' isn't known DL_LOADADDR_TYPE load_addr; ^~~~~~~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-sysdep.h:51:41: error: 'dl_boot_got_pointer' undeclared (first use in this function); did you mean '__builtin_eh_pointer'? (__dl_init_loadaddr_map (&(LOADADDR), dl_boot_got_pointer, \ ^ ldso/ldso/dl-startup.c:193:2: note: in expansion of macro 'DL_INIT_LOADADDR_BOOT' DL_INIT_LOADADDR_BOOT(load_addr, auxvt[AT_BASE].a_un.a_val); ^~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-sysdep.h:51:41: note: each undeclared identifier is reported only once for each function it appears in (__dl_init_loadaddr_map (&(LOADADDR), dl_boot_got_pointer, \ ^ ldso/ldso/dl-startup.c:193:2: note: in expansion of macro 'DL_INIT_LOADADDR_BOOT' DL_INIT_LOADADDR_BOOT(load_addr, auxvt[AT_BASE].a_un.a_val); ^~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-sysdep.h:52:7: error: 'dl_boot_ldsomap' undeclared (first use in this function) dl_boot_ldsomap ?: dl_boot_progmap)) ^ ldso/ldso/dl-startup.c:193:2: note: in expansion of macro 'DL_INIT_LOADADDR_BOOT' DL_INIT_LOADADDR_BOOT(load_addr, auxvt[AT_BASE].a_un.a_val); ^~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-sysdep.h:52:26: error: 'dl_boot_progmap' undeclared (first use in this function); did you mean 'dl_boot_ldsomap'? dl_boot_ldsomap ?: dl_boot_progmap)) ^ ldso/ldso/dl-startup.c:193:2: note: in expansion of macro 'DL_INIT_LOADADDR_BOOT' DL_INIT_LOADADDR_BOOT(load_addr, auxvt[AT_BASE].a_un.a_val); ^~~~~~~~~~~~~~~~~~~~~ ./ldso/ldso/arm/../fdpic/dl-sysdep.h:91:13: error: 'dl_boot_ldso_dyn_pointer' undeclared (first use in this function); did you mean 'dl_boot_got_pointer'? ((dpnt) = dl_boot_ldso_dyn_pointer) ^ ldso/ldso/dl-startup.c:219:2: note: in expansion of macro 'DL_BOOT_COMPUTE_DYN' DL_BOOT_COMPUTE_DYN(dpnt, got, (DL_LOADADDR_TYPE)header); ^~~~~~~~~~~~~~~~~~~ In file included from ldso/ldso/ldso.c:86:0: ldso/ldso/dl-startup.c:233:57: error: type of formal parameter 4 is incomplete _dl_parse_dynamic_info(dpnt, tpnt->dynamic_info, NULL, load_addr); ^~~~~~~~~ ldso/ldso/dl-startup.c:358:31: error: type of formal parameter 2 is incomplete _dl_get_ready_to_run(tpnt, load_addr, auxvt, envp, argv ^~~~~~~~~ ldso/ldso/dl-startup.c:125:13: warning: variable 'got' set but not used [-Wunused-but-set-variable] ElfW(Addr) got; ^~~ ldso/ldso/dl-startup.c:124:19: warning: unused variable 'load_addr' [-Wunused-variable] DL_LOADADDR_TYPE load_addr; ^~~~~~~~~ In file included from ldso/ldso/ldso.c:88:0: ldso/ldso/dl-array.c: At top level: ldso/ldso/dl-array.c:34:52: error: parameter 3 ('loadaddr') has incomplete type DL_LOADADDR_TYPE loadaddr) ^~~~~~~~ ldso/ldso/dl-array.c:33:13: warning: function declaration isn't a prototype [-Wstrict-prototypes] static void _dl_run_array_forward(unsigned long array, unsigned long size, ^~~~~~~~~~~~~~~~~~~~~ ldso/ldso/ldso.c:351:28: error: parameter 2 ('load_addr') has incomplete type DL_LOADADDR_TYPE load_addr, ^~~~~~~~~ ldso/ldso/ldso.c:350:29: warning: function declaration isn't a prototype [-Wstrict-prototypes] static struct elf_resolve * add_ldso(struct elf_resolve *tpnt, ^~~~~~~~ ldso/ldso/ldso.c: In function 'add_ldso': ldso/ldso/ldso.c:363:48: error: type of formal parameter 2 is incomplete tpnt = _dl_add_elf_hash_table(tpnt->libname, tpnt->loadaddr, ^~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ldso/ldso/ldso.c: At top level: ./ldso/ldso/arm/../fdpic/dl-sysdep.h:114:14: warning: 'struct elf32_fdpic_loadmap' declared inside parameter list will not be visible outside of this definition or declaration , struct elf32_fdpic_loadmap *dl_boot_progmap, Elf32_Addr dl_boot_got_pointer ^ ldso/ldso/ldso.c:426:6: note: in expansion of macro 'DL_GET_READY_TO_RUN_EXTRA_PARMS' DL_GET_READY_TO_RUN_EXTRA_PARMS) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ldso/ldso/ldso.c:424:71: error: parameter 2 ('load_addr') has incomplete type void *_dl_get_ready_to_run(struct elf_resolve *tpnt, DL_LOADADDR_TYPE load_addr, ^~~~~~~~~ In file included from ./ldso/ldso/arm/dl-sysdep.h:135:0, from ./ldso/include/dl-defs.h:77, from ./ldso/include/dl-string.h:15, from ./ldso/include/ldso.h:53, from ldso/ldso/ldso.c:32: ldso/ldso/ldso.c: In function '_dl_get_ready_to_run': ./ldso/ldso/arm/../fdpic/dl-sysdep.h:55:44: warning: passing argument 3 of '__dl_init_loadaddr_map' from incompatible pointer type [-Wincompatible-pointer-types] (__dl_init_loadaddr_map (&(LOADADDR), 0, dl_boot_progmap)) ^ ldso/ldso/ldso.c:650:5: note: in expansion of macro 'DL_INIT_LOADADDR_PROG' DL_INIT_LOADADDR_PROG(app_tpnt->loadaddr, auxvt[AT_PHDR].a_un.a_val - phdr->p_vaddr); ^~~~~~~~~~~~~~~~~~~~~ In file included from ./ldso/ldso/arm/dl-inlines.h:1:0, from ./ldso/include/ldso.h:183, from ldso/ldso/ldso.c:32: ./ldso/ldso/arm/../fdpic/dl-inlines.h:14:1: note: expected 'struct elf32_fdpic_loadmap *' but argument is of type 'struct elf32_fdpic_loadmap *' __dl_init_loadaddr_map(struct elf32_fdpic_loadaddr *loadaddr, Elf32_Addr dl_boot_got_pointer, ^~~~~~~~~~~~~~~~~~~~~~ ldso/ldso/ldso.c:676:69: error: type of formal parameter 4 is incomplete _dl_parse_dynamic_info(dpnt, app_tpnt->dynamic_info, debug_addr, app_tpnt->loadaddr); ^~~~~~~~ ldso/ldso/ldso.c:711:52: error: type of formal parameter 2 is incomplete app_tpnt = _dl_add_elf_hash_table(_dl_progname, app_tpnt->loadaddr, ^~~~~~~~ In file included from ldso/ldso/ldso.c:1460:0: ldso/ldso/dl-hash.c: At top level: ldso/ldso/dl-hash.c:90:19: error: parameter 2 ('loadaddr') has incomplete type DL_LOADADDR_TYPE loadaddr, unsigned long *dynamic_info, unsigned long dynamic_addr, ^~~~~~~~ In file included from ldso/ldso/ldso.c:1461:0: ldso/ldso/dl-elf.c: In function '_dl_load_elf_shared_library': ldso/ldso/dl-elf.c:535:19: error: storage size of 'lib_loadaddr' isn't known DL_LOADADDR_TYPE lib_loadaddr; ^~~~~~~~~~~~ ldso/ldso/dl-elf.c:780:64: error: type of formal parameter 4 is incomplete rtld_flags = _dl_parse_dynamic_info(dpnt, dynamic_info, NULL, lib_loadaddr); ^~~~~~~~~~~~ ldso/ldso/dl-elf.c:822:41: error: type of formal parameter 2 is incomplete tpnt = _dl_add_elf_hash_table(libname, lib_loadaddr, dynamic_info, ^~~~~~~~~~~~ ldso/ldso/dl-elf.c:535:19: warning: unused variable 'lib_loadaddr' [-Wunused-variable] DL_LOADADDR_TYPE lib_loadaddr; ^~~~~~~~~~~~ In file included from ldso/ldso/ldso.c:1461:0: ldso/ldso/dl-elf.c: At top level: ldso/ldso/dl-elf.c:1186:72: error: parameter 4 ('load_off') has incomplete type void *debug_addr, DL_LOADADDR_TYPE load_off) ^~~~~~~~ ldso/ldso/dl-elf.c: In function '_dl_parse_dynamic_info': ldso/ldso/dl-elf.c:1189:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ Makerules:370: recipe for target 'ldso/ldso/ldso.oS' failed make[6]: *** [ldso/ldso/ldso.oS] Error 1 Makefile:335: recipe for target '/home/wbx/embedded-test/openadk/toolchain_build_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/w-uClibc-ng-1.0.30-1/uClibc-ng-1.0.30/.compiled' failed make[5]: *** [/home/wbx/embedded-test/openadk/toolchain_build_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm/w-uClibc-ng-1.0.30-1/uClibc-ng-1.0.30/.compiled] Error 2 Makefile:116: recipe for target 'uclibc-ng-compile' failed make[4]: *** [uclibc-ng-compile] Error 2 mk/build.mk:238: recipe for target 'toolchain/final' failed make[3]: *** [toolchain/final] Error 2 /home/wbx/embedded-test/openadk/mk/build.mk:174: recipe for target 'world' failed make[2]: *** [world] Error 2
On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > Hi Christophe, > Waldemar Brodkorb wrote, > > > Hi Christophe, > > > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > > > > ARM v5 soft eabi arm mode fails to compile, see the attached error > log. You can check with embedded-test.sh if you like. > > Any idea? All patches appliend on top of master, Thanks for testing this configuration. I left FDPIC-only code activated unconditionally. Can you try the attached small patch? I have an embedded-test.sh build running now. Sorry, I didn't know about this script, I have used armv5 as arch, is it the one you meant? I am on holidays atm, so I may not respond timely for a while. Thanks, Christophe > > best regards > Waldemar diff --git a/ldso/ldso/arm/dl-sysdep.h b/ldso/ldso/arm/dl-sysdep.h index 2bb0023..be53bd6 100644 --- a/ldso/ldso/arm/dl-sysdep.h +++ b/ldso/ldso/arm/dl-sysdep.h @@ -77,6 +77,7 @@ unsigned long _dl_linux_resolver(struct elf_resolve * tpnt, int reloc_entry); ELF_RTYPE_CLASS_NOCOPY iff TYPE should not be allowed to resolve to one of the main executable's symbols, as for a COPY reloc. +#ifdef __FDPIC__ Avoid R_ARM_ABS32 to go through the PLT so that R_ARM_TARGET1 translated to R_ARM_ABS32 doesn't use the PLT: otherwise, this breaks init_array because functions are referenced through the @@ -87,6 +88,13 @@ unsigned long _dl_linux_resolver(struct elf_resolve * tpnt, int reloc_entry); || (type) == R_ARM_TLS_DTPOFF32 || (type) == R_ARM_TLS_TPOFF32) \ * ELF_RTYPE_CLASS_PLT) \ | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)) +#else +#define elf_machine_type_class(type) \ + ((((type) == R_ARM_JUMP_SLOT || (type) == R_ARM_TLS_DTPMOD32 \ + || (type) == R_ARM_TLS_DTPOFF32 || (type) == R_ARM_TLS_TPOFF32) \ + - ELF_RTYPE_CLASS_PLT) \ + | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)) +#endf /* __FDPIC__ */ /* Return the link-time address of _DYNAMIC. Conveniently, this is the first element of the GOT. We used to use the PIC register to do this @@ -125,6 +133,7 @@ elf_machine_dynamic (void) extern char __dl_start[] __asm__("_dl_start"); +#ifdef __FDPIC__ /* We must force strings used early in the bootstrap into the data segment. */ #undef SEND_EARLY_STDERR @@ -133,6 +142,7 @@ extern char __dl_start[] __asm__("_dl_start"); #undef INIT_GOT #include "../fdpic/dl-sysdep.h" +#endif /* __FDPIC__ */ /* Return the run-time load address of the shared object. */ static __always_inline Elf32_Addr __attribute__ ((unused))
Hi, Christophe Lyon wrote, > On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > Hi Christophe, > > Waldemar Brodkorb wrote, > > > > > Hi Christophe, > > > > > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > > > > > > > ARM v5 soft eabi arm mode fails to compile, see the attached error > > log. You can check with embedded-test.sh if you like. > > > > Any idea? All patches appliend on top of master, > > Thanks for testing this configuration. > > I left FDPIC-only code activated unconditionally. > > Can you try the attached small patch? Even fixing this small typo in #endf it errors out. > I have an embedded-test.sh build running now. Sorry, I didn't know > about this script, I have used armv5 as arch, is it the one you meant? somthing like this, uclibc-ng is a directory including all patches: mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose > I am on holidays atm, so I may not respond timely for a while. Okay, thanks for the info. best regards Waldemar
On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > Hi, > Christophe Lyon wrote, > > > On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > > > Hi Christophe, > > > Waldemar Brodkorb wrote, > > > > > > > Hi Christophe, > > > > > > > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > > > > > > > > > > ARM v5 soft eabi arm mode fails to compile, see the attached error > > > log. You can check with embedded-test.sh if you like. > > > > > > Any idea? All patches appliend on top of master, > > > > Thanks for testing this configuration. > > > > I left FDPIC-only code activated unconditionally. > > > > Can you try the attached small patch? > > Even fixing this small typo in #endf it errors out. > OK, here is an updated version of the previous patch. > > I have an embedded-test.sh build running now. Sorry, I didn't know > > about this script, I have used armv5 as arch, is it the one you meant? > > somthing like this, uclibc-ng is a directory including all patches: > mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose Is there a way to avoid (re)creating all the source tarballs? It's taking ages > > > I am on holidays atm, so I may not respond timely for a while. > > Okay, thanks for the info. > > best regards > Waldemar diff --git a/ldso/ldso/arm/dl-startup.h b/ldso/ldso/arm/dl-startup.h index b5f7d73..06c95cb 100644 --- a/ldso/ldso/arm/dl-startup.h +++ b/ldso/ldso/arm/dl-startup.h @@ -245,6 +245,7 @@ void PERFORM_BOOTSTRAP_RELOC(ELF_RELOC *rpnt, unsigned long *reloc_addr, break; case R_ARM_COPY: break; +#ifdef __FDPIC__ case R_ARM_FUNCDESC_VALUE: { struct funcdesc_value *dst = (struct funcdesc_value *) reloc_addr; @@ -253,6 +254,7 @@ void PERFORM_BOOTSTRAP_RELOC(ELF_RELOC *rpnt, unsigned long *reloc_addr, dst->got_value = load_addr.got_value; } break; +#endif default: SEND_STDERR("Unsupported relocation type\n"); _dl_exit(1); diff --git a/ldso/ldso/arm/dl-sysdep.h b/ldso/ldso/arm/dl-sysdep.h index 2bb0023..0288b0e 100644 --- a/ldso/ldso/arm/dl-sysdep.h +++ b/ldso/ldso/arm/dl-sysdep.h @@ -75,9 +75,10 @@ unsigned long _dl_linux_resolver(struct elf_resolve * tpnt, int reloc_entry); define the value. ELF_RTYPE_CLASS_NOCOPY iff TYPE should not be allowed to resolve to one - of the main executable's symbols, as for a COPY reloc. + of the main executable's symbols, as for a COPY reloc. */ - Avoid R_ARM_ABS32 to go through the PLT so that R_ARM_TARGET1 +#ifdef __FDPIC__ +/* Avoid R_ARM_ABS32 to go through the PLT so that R_ARM_TARGET1 translated to R_ARM_ABS32 doesn't use the PLT: otherwise, this breaks init_array because functions are referenced through the PLT. */ @@ -87,6 +88,13 @@ unsigned long _dl_linux_resolver(struct elf_resolve * tpnt, int reloc_entry); || (type) == R_ARM_TLS_DTPOFF32 || (type) == R_ARM_TLS_TPOFF32) \ * ELF_RTYPE_CLASS_PLT) \ | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)) +#else +#define elf_machine_type_class(type) \ + ((((type) == R_ARM_JUMP_SLOT || (type) == R_ARM_TLS_DTPMOD32 \ + || (type) == R_ARM_TLS_DTPOFF32 || (type) == R_ARM_TLS_TPOFF32) \ + - ELF_RTYPE_CLASS_PLT) \ + | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)) +#endif /* __FDPIC__ */ /* Return the link-time address of _DYNAMIC. Conveniently, this is the first element of the GOT. We used to use the PIC register to do this @@ -125,6 +133,7 @@ elf_machine_dynamic (void) extern char __dl_start[] __asm__("_dl_start"); +#ifdef __FDPIC__ /* We must force strings used early in the bootstrap into the data segment. */ #undef SEND_EARLY_STDERR @@ -133,6 +142,7 @@ extern char __dl_start[] __asm__("_dl_start"); #undef INIT_GOT #include "../fdpic/dl-sysdep.h" +#endif /* __FDPIC__ */ /* Return the run-time load address of the shared object. */ static __always_inline Elf32_Addr __attribute__ ((unused)) @@ -163,7 +173,11 @@ elf_machine_load_address (void) } static __always_inline void +#ifdef __FDPIC__ elf_machine_relative (DL_LOADADDR_TYPE load_off, const Elf32_Addr rel_addr, +#else +elf_machine_relative (Elf32_Addr load_off, const Elf32_Addr rel_addr, +#endif Elf32_Word relative_count) { #if defined(__FDPIC__) diff --git a/ldso/ldso/arm/elfinterp.c b/ldso/ldso/arm/elfinterp.c index 2444ed7..4c26835 100644 --- a/ldso/ldso/arm/elfinterp.c +++ b/ldso/ldso/arm/elfinterp.c @@ -343,6 +343,7 @@ _dl_do_reloc (struct elf_resolve *tpnt,struct r_scope_elem *scope, _dl_memcpy((void *) reloc_addr, (void *) symbol_addr, symtab[symtab_index].st_size); break; +#ifdef __FDPIC__ case R_ARM_FUNCDESC_VALUE: { struct funcdesc_value funcval; @@ -371,6 +372,7 @@ _dl_do_reloc (struct elf_resolve *tpnt,struct r_scope_elem *scope, *reloc_addr = reloc_value; } break; +#endif #if defined USE_TLS && USE_TLS case R_ARM_TLS_DTPMOD32: *reloc_addr = def_mod->l_tls_modid; @@ -422,6 +424,7 @@ _dl_do_lazy_reloc (struct elf_resolve *tpnt, struct r_scope_elem *scope, case R_ARM_JUMP_SLOT: *reloc_addr = DL_RELOC_ADDR(tpnt->loadaddr, *reloc_addr); break; +#ifdef __FDPIC__ case R_ARM_FUNCDESC_VALUE: { struct funcdesc_value *dst = (struct funcdesc_value *) reloc_addr; @@ -430,6 +433,7 @@ _dl_do_lazy_reloc (struct elf_resolve *tpnt, struct r_scope_elem *scope, dst->got_value = tpnt->loadaddr.got_value; } break; +#endif default: return -1; /*call _dl_exit(1) */ }
Hi, Christophe Lyon wrote, > On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > Hi, > > Christophe Lyon wrote, > > > > > On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > > > > > Hi Christophe, > > > > Waldemar Brodkorb wrote, > > > > > > > > > Hi Christophe, > > > > > > > > > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > > > > > > > > > > > > > ARM v5 soft eabi arm mode fails to compile, see the attached error > > > > log. You can check with embedded-test.sh if you like. > > > > > > > > Any idea? All patches appliend on top of master, > > > > > > Thanks for testing this configuration. > > > > > > I left FDPIC-only code activated unconditionally. > > > > > > Can you try the attached small patch? > > > > Even fixing this small typo in #endf it errors out. > > > OK, here is an updated version of the previous patch. Works for the ldso, but I think we need a symbol to differentiate between ELF and FDPIC. See attached error. > > > I have an embedded-test.sh build running now. Sorry, I didn't know > > > about this script, I have used armv5 as arch, is it the one you meant? > > > > somthing like this, uclibc-ng is a directory including all patches: > > mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose > > Is there a way to avoid (re)creating all the source tarballs? It's taking ages It only recreates uclibc-ng tarball. (or any git ones). You can do on a failure: cd openadk make v best regards Waldemar
attachment /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm_nommu/usr/bin/arm-openadk-uclinux-uclibceabi-gcc -c libpthread/linuxthreads_db/td_thr_setprio.c -o libpthread/linuxthreads_db/td_thr_setprio.os -Wall -Wstrict-prototypes -Wstrict-aliasing -Wno-nonnull-compare -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -mlittle-endian -fno-stack-protector -nostdinc -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/arm -I./libc/sysdeps/linux -I./ldso/ldso/arm -I./ldso/include -I. -DSTATIC -Os -fstrict-aliasing -fwrapv -fno-ident -mcpu=arm926ej-s -mfloat-abi=soft -Wl,-elf2flt -static -Os -pipe -fomit-frame-pointer -marm -Wa,-mfloat-abi=soft -I./libpthread/linuxthreads/sysdeps/unix/sysv/linux/arm -I./libpthread/linuxthreads/sysdeps/arm -I./libpthread/linuxthreads/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads/sysdeps/pthread -I./libpthread/linuxthreads -I./libpthread -I./libc/sysdeps/linux/common -isystem /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm_nommu/usr/lib/gcc/arm-openadk-uclinux-uclibceabi/7.3.0/include-fixed -isystem /home/wbx/embedded-test/openadk/toolchain_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm_nommu/usr/lib/gcc/arm-openadk-uclinux-uclibceabi/7.3.0/include -I/home/wbx/embedded-test/openadk/target_qemu-arm-versatilepb_uclibc-ng_arm926ej_s_soft_eabi_arm_nommu/usr/include/ -DNDEBUG -DNOT_IN_libc -DLIBPTHREAD_SO="\"libpthread.so.1\"" -DIN_LIB=libpthread -mfdpic -MT libpthread/linuxthreads_db/td_thr_setprio.os -MD -MP -MF libpthread/linuxthreads_db/.td_thr_setprio.os.dep arm-openadk-uclinux-uclibceabi-gcc: error: unrecognized command line option '-mfdpic'; did you mean '-fpic'? Makerules:369: recipe for target 'libpthread/linuxthreads_db/td_thr_setprio.os' failed
On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb <mail@waldemar-brodkorb.de> wrote: > > Hi, > Christophe Lyon wrote, > > > On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > > > Hi, > > > Christophe Lyon wrote, > > > > > > > On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > > > > > > > > > Hi Christophe, > > > > > Waldemar Brodkorb wrote, > > > > > > > > > > > Hi Christophe, > > > > > > > > > > > > i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > > > > > > > > > > > > > > > > ARM v5 soft eabi arm mode fails to compile, see the attached error > > > > > log. You can check with embedded-test.sh if you like. > > > > > > > > > > Any idea? All patches appliend on top of master, > > > > > > > > Thanks for testing this configuration. > > > > > > > > I left FDPIC-only code activated unconditionally. > > > > > > > > Can you try the attached small patch? > > > > > > Even fixing this small typo in #endf it errors out. > > > > > OK, here is an updated version of the previous patch. > > Works for the ldso, but I think we need a symbol to differentiate > between ELF and FDPIC. > See attached error. Strange, the build succeeded for me. I don't understand where this -mfdpic option comes from? It is not part of the patches I sent, unless I'm mistaken: it would be "embedded" in GCC if configured for FDPIC, which is not the case in this build for armv5. > > > > > I have an embedded-test.sh build running now. Sorry, I didn't know > > > > about this script, I have used armv5 as arch, is it the one you meant? > > > > > > somthing like this, uclibc-ng is a directory including all patches: > > > mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose > > > > Is there a way to avoid (re)creating all the source tarballs? It's taking ages > > It only recreates uclibc-ng tarball. (or any git ones). OK... I use git trees for binutils, gcc and linux ;( > You can do on a failure: > cd openadk > make v > > best regards > Waldemar
Hi, okay, that was already the next test armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. Will you sent a complete patch with sob for the previous error? best regards Waldemar > Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > > On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb > <mail@waldemar-brodkorb.de> wrote: >> >> Hi, >> Christophe Lyon wrote, >> >>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>> >>>> Hi, >>>> Christophe Lyon wrote, >>>> >>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>> >>>>>> Hi Christophe, >>>>>> Waldemar Brodkorb wrote, >>>>>> >>>>>>> Hi Christophe, >>>>>>> >>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. >>>>>>> >>>>>> >>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error >>>>>> log. You can check with embedded-test.sh if you like. >>>>>> >>>>>> Any idea? All patches appliend on top of master, >>>>> >>>>> Thanks for testing this configuration. >>>>> >>>>> I left FDPIC-only code activated unconditionally. >>>>> >>>>> Can you try the attached small patch? >>>> >>>> Even fixing this small typo in #endf it errors out. >>>> >>> OK, here is an updated version of the previous patch. >> >> Works for the ldso, but I think we need a symbol to differentiate >> between ELF and FDPIC. >> See attached error. > > Strange, the build succeeded for me. I don't understand where this > -mfdpic option comes from? > It is not part of the patches I sent, unless I'm mistaken: it would be > "embedded" in GCC if configured for FDPIC, which is not the case in > this build for armv5. > > >> >>>>> I have an embedded-test.sh build running now. Sorry, I didn't know >>>>> about this script, I have used armv5 as arch, is it the one you meant? >>>> >>>> somthing like this, uclibc-ng is a directory including all patches: >>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose >>> >>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages >> >> It only recreates uclibc-ng tarball. (or any git ones). > OK... I use git trees for binutils, gcc and linux ;( > >> You can do on a failure: >> cd openadk >> make v >> >> best regards >> Waldemar >
On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > Hi, > > okay, that was already the next test > armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. I'm not sure to understand; if by "now" you mean with my uclibc-ng patch series, then no. At least not yet. As said in the cover letter this patch series supports only armv7. And as noticed by Thomas, it doesn't yet support armv7m. The plan is definitely to support armv7m. So you probably want to create a new config armv7-nommu-arm in your script. Since I'm not familiar with this script nor openadk, I don't know what this implies. I thought you wanted to first make sure my uclibc-ng patch series didn't break existing configs. If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC patches (see link in cover letter). You also need recent binutils. I don't know if/how your script handles that since I noticed "7.3.0" in the GCC error messages you shared, which seems to indicate you are not using the most recent GCC. And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. This will configure GCC is the right mode, no need to use flags such as -mfdpic. > Will you sent a complete patch with sob for the previous error? Which previous error? If you mean the latest you reported involving -mfdpic, then I hope my answer just above clarifies. If you mean the broken armv5 build, then yes, but the patch I sent recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC code for arm" What the practice on this list? Shall I send v2 of patch 4/32 asap, on rather wait for feedback on other patches and then send a v2 of the whole series? Thanks, Christophe > best regards > > Waldemar > > > Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > > > > On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb > > <mail@waldemar-brodkorb.de> wrote: > >> > >> Hi, > >> Christophe Lyon wrote, > >> > >>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>>> > >>>> Hi, > >>>> Christophe Lyon wrote, > >>>> > >>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>>>>> > >>>>>> Hi Christophe, > >>>>>> Waldemar Brodkorb wrote, > >>>>>> > >>>>>>> Hi Christophe, > >>>>>>> > >>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > >>>>>>> > >>>>>> > >>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error > >>>>>> log. You can check with embedded-test.sh if you like. > >>>>>> > >>>>>> Any idea? All patches appliend on top of master, > >>>>> > >>>>> Thanks for testing this configuration. > >>>>> > >>>>> I left FDPIC-only code activated unconditionally. > >>>>> > >>>>> Can you try the attached small patch? > >>>> > >>>> Even fixing this small typo in #endf it errors out. > >>>> > >>> OK, here is an updated version of the previous patch. > >> > >> Works for the ldso, but I think we need a symbol to differentiate > >> between ELF and FDPIC. > >> See attached error. > > > > Strange, the build succeeded for me. I don't understand where this > > -mfdpic option comes from? > > It is not part of the patches I sent, unless I'm mistaken: it would be > > "embedded" in GCC if configured for FDPIC, which is not the case in > > this build for armv5. > > > > > >> > >>>>> I have an embedded-test.sh build running now. Sorry, I didn't know > >>>>> about this script, I have used armv5 as arch, is it the one you meant? > >>>> > >>>> somthing like this, uclibc-ng is a directory including all patches: > >>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose > >>> > >>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages > >> > >> It only recreates uclibc-ng tarball. (or any git ones). > > OK... I use git trees for binutils, gcc and linux ;( > > > >> You can do on a failure: > >> cd openadk > >> make v > >> > >> best regards > >> Waldemar > > >
Hi, sorry for the confusion. I take care about the last failure. The build runs further so, I give you feedback once it is finished. I can squash the patch before pushing, best regards Waldemar > Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > >> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >> >> Hi, >> >> okay, that was already the next test >> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. > I'm not sure to understand; if by "now" you mean with my uclibc-ng > patch series, then no. At least not yet. > As said in the cover letter this patch series supports only armv7. And > as noticed by Thomas, it doesn't yet support armv7m. > The plan is definitely to support armv7m. > > So you probably want to create a new config armv7-nommu-arm in your script. > > Since I'm not familiar with this script nor openadk, I don't know what > this implies. > > I thought you wanted to first make sure my uclibc-ng patch series > didn't break existing configs. > > If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC > patches (see link in cover letter). You also need recent binutils. I > don't know if/how your script handles that since I noticed "7.3.0" in > the GCC error messages you shared, which seems to indicate you are not > using the most recent GCC. > > And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. > This will configure GCC is the right mode, no need to use flags such as -mfdpic. > > >> Will you sent a complete patch with sob for the previous error? > Which previous error? If you mean the latest you reported involving > -mfdpic, then I hope my answer just above clarifies. > > If you mean the broken armv5 build, then yes, but the patch I sent > recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC > code for arm" > > What the practice on this list? Shall I send v2 of patch 4/32 asap, on > rather wait for feedback on other patches and then send a v2 of the > whole series? > > Thanks, > > Christophe > > >> best regards >> >> Waldemar >> >>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>> >>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb >>> <mail@waldemar-brodkorb.de> wrote: >>>> >>>> Hi, >>>> Christophe Lyon wrote, >>>> >>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>> >>>>>> Hi, >>>>>> Christophe Lyon wrote, >>>>>> >>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>> >>>>>>>> Hi Christophe, >>>>>>>> Waldemar Brodkorb wrote, >>>>>>>> >>>>>>>>> Hi Christophe, >>>>>>>>> >>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. >>>>>>>>> >>>>>>>> >>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error >>>>>>>> log. You can check with embedded-test.sh if you like. >>>>>>>> >>>>>>>> Any idea? All patches appliend on top of master, >>>>>>> >>>>>>> Thanks for testing this configuration. >>>>>>> >>>>>>> I left FDPIC-only code activated unconditionally. >>>>>>> >>>>>>> Can you try the attached small patch? >>>>>> >>>>>> Even fixing this small typo in #endf it errors out. >>>>>> >>>>> OK, here is an updated version of the previous patch. >>>> >>>> Works for the ldso, but I think we need a symbol to differentiate >>>> between ELF and FDPIC. >>>> See attached error. >>> >>> Strange, the build succeeded for me. I don't understand where this >>> -mfdpic option comes from? >>> It is not part of the patches I sent, unless I'm mistaken: it would be >>> "embedded" in GCC if configured for FDPIC, which is not the case in >>> this build for armv5. >>> >>> >>>> >>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know >>>>>>> about this script, I have used armv5 as arch, is it the one you meant? >>>>>> >>>>>> somthing like this, uclibc-ng is a directory including all patches: >>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose >>>>> >>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages >>>> >>>> It only recreates uclibc-ng tarball. (or any git ones). >>> OK... I use git trees for binutils, gcc and linux ;( >>> >>>> You can do on a failure: >>>> cd openadk >>>> make v >>>> >>>> best regards >>>> Waldemar >>> >> >
Hi, the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling. Can be seen with --test=libc in embedded-test.sh. So there is still some regression for arm and ELF. Any idea? best regards Waldemar > Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>: > > Hi, > > sorry for the confusion. > I take care about the last failure. > The build runs further so, I give you feedback once it is finished. > > I can squash the patch before pushing, > > best regards > Waldemar > >>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>> >>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>> >>> Hi, >>> >>> okay, that was already the next test >>> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. >> I'm not sure to understand; if by "now" you mean with my uclibc-ng >> patch series, then no. At least not yet. >> As said in the cover letter this patch series supports only armv7. And >> as noticed by Thomas, it doesn't yet support armv7m. >> The plan is definitely to support armv7m. >> >> So you probably want to create a new config armv7-nommu-arm in your script. >> >> Since I'm not familiar with this script nor openadk, I don't know what >> this implies. >> >> I thought you wanted to first make sure my uclibc-ng patch series >> didn't break existing configs. >> >> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC >> patches (see link in cover letter). You also need recent binutils. I >> don't know if/how your script handles that since I noticed "7.3.0" in >> the GCC error messages you shared, which seems to indicate you are not >> using the most recent GCC. >> >> And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. >> This will configure GCC is the right mode, no need to use flags such as -mfdpic. >> >> >>> Will you sent a complete patch with sob for the previous error? >> Which previous error? If you mean the latest you reported involving >> -mfdpic, then I hope my answer just above clarifies. >> >> If you mean the broken armv5 build, then yes, but the patch I sent >> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC >> code for arm" >> >> What the practice on this list? Shall I send v2 of patch 4/32 asap, on >> rather wait for feedback on other patches and then send a v2 of the >> whole series? >> >> Thanks, >> >> Christophe >> >> >>> best regards >>> >>> Waldemar >>> >>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>>> >>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb >>>> <mail@waldemar-brodkorb.de> wrote: >>>>> >>>>> Hi, >>>>> Christophe Lyon wrote, >>>>> >>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> Christophe Lyon wrote, >>>>>>> >>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>>> >>>>>>>>> Hi Christophe, >>>>>>>>> Waldemar Brodkorb wrote, >>>>>>>>> >>>>>>>>>> Hi Christophe, >>>>>>>>>> >>>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. >>>>>>>>>> >>>>>>>>> >>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error >>>>>>>>> log. You can check with embedded-test.sh if you like. >>>>>>>>> >>>>>>>>> Any idea? All patches appliend on top of master, >>>>>>>> >>>>>>>> Thanks for testing this configuration. >>>>>>>> >>>>>>>> I left FDPIC-only code activated unconditionally. >>>>>>>> >>>>>>>> Can you try the attached small patch? >>>>>>> >>>>>>> Even fixing this small typo in #endf it errors out. >>>>>>> >>>>>> OK, here is an updated version of the previous patch. >>>>> >>>>> Works for the ldso, but I think we need a symbol to differentiate >>>>> between ELF and FDPIC. >>>>> See attached error. >>>> >>>> Strange, the build succeeded for me. I don't understand where this >>>> -mfdpic option comes from? >>>> It is not part of the patches I sent, unless I'm mistaken: it would be >>>> "embedded" in GCC if configured for FDPIC, which is not the case in >>>> this build for armv5. >>>> >>>> >>>>> >>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know >>>>>>>> about this script, I have used armv5 as arch, is it the one you meant? >>>>>>> >>>>>>> somthing like this, uclibc-ng is a directory including all patches: >>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose >>>>>> >>>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages >>>>> >>>>> It only recreates uclibc-ng tarball. (or any git ones). >>>> OK... I use git trees for binutils, gcc and linux ;( >>>> >>>>> You can do on a failure: >>>>> cd openadk >>>>> make v >>>>> >>>>> best regards >>>>> Waldemar >>>> >>> >> > > _______________________________________________ > devel mailing list > devel@uclibc-ng.org > https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > > Hi, > > the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling. > > Can be seen with --test=libc in embedded-test.sh. It looks like tests are looping with getty error messages, is that what you saw? > > So there is still some regression for arm and ELF. > > Any idea? Not yet. How can I run embedded-test.sh twice with different uclibc-ng version? (the original one, and the one with my patches) Should I restart from a new directory? > best regards > Waldemar > > > Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>: > > > > Hi, > > > > sorry for the confusion. > > I take care about the last failure. > > The build runs further so, I give you feedback once it is finished. > > > > I can squash the patch before pushing, > > > > best regards > > Waldemar > > > >>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > >>> > >>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>> > >>> Hi, > >>> > >>> okay, that was already the next test > >>> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. > >> I'm not sure to understand; if by "now" you mean with my uclibc-ng > >> patch series, then no. At least not yet. > >> As said in the cover letter this patch series supports only armv7. And > >> as noticed by Thomas, it doesn't yet support armv7m. > >> The plan is definitely to support armv7m. > >> > >> So you probably want to create a new config armv7-nommu-arm in your script. > >> > >> Since I'm not familiar with this script nor openadk, I don't know what > >> this implies. > >> > >> I thought you wanted to first make sure my uclibc-ng patch series > >> didn't break existing configs. > >> > >> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC > >> patches (see link in cover letter). You also need recent binutils. I > >> don't know if/how your script handles that since I noticed "7.3.0" in > >> the GCC error messages you shared, which seems to indicate you are not > >> using the most recent GCC. > >> > >> And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. > >> This will configure GCC is the right mode, no need to use flags such as -mfdpic. > >> > >> > >>> Will you sent a complete patch with sob for the previous error? > >> Which previous error? If you mean the latest you reported involving > >> -mfdpic, then I hope my answer just above clarifies. > >> > >> If you mean the broken armv5 build, then yes, but the patch I sent > >> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC > >> code for arm" > >> > >> What the practice on this list? Shall I send v2 of patch 4/32 asap, on > >> rather wait for feedback on other patches and then send a v2 of the > >> whole series? > >> > >> Thanks, > >> > >> Christophe > >> > >> > >>> best regards > >>> > >>> Waldemar > >>> > >>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > >>>> > >>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb > >>>> <mail@waldemar-brodkorb.de> wrote: > >>>>> > >>>>> Hi, > >>>>> Christophe Lyon wrote, > >>>>> > >>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> Christophe Lyon wrote, > >>>>>>> > >>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>>>>>>>> > >>>>>>>>> Hi Christophe, > >>>>>>>>> Waldemar Brodkorb wrote, > >>>>>>>>> > >>>>>>>>>> Hi Christophe, > >>>>>>>>>> > >>>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error > >>>>>>>>> log. You can check with embedded-test.sh if you like. > >>>>>>>>> > >>>>>>>>> Any idea? All patches appliend on top of master, > >>>>>>>> > >>>>>>>> Thanks for testing this configuration. > >>>>>>>> > >>>>>>>> I left FDPIC-only code activated unconditionally. > >>>>>>>> > >>>>>>>> Can you try the attached small patch? > >>>>>>> > >>>>>>> Even fixing this small typo in #endf it errors out. > >>>>>>> > >>>>>> OK, here is an updated version of the previous patch. > >>>>> > >>>>> Works for the ldso, but I think we need a symbol to differentiate > >>>>> between ELF and FDPIC. > >>>>> See attached error. > >>>> > >>>> Strange, the build succeeded for me. I don't understand where this > >>>> -mfdpic option comes from? > >>>> It is not part of the patches I sent, unless I'm mistaken: it would be > >>>> "embedded" in GCC if configured for FDPIC, which is not the case in > >>>> this build for armv5. > >>>> > >>>> > >>>>> > >>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know > >>>>>>>> about this script, I have used armv5 as arch, is it the one you meant? > >>>>>>> > >>>>>>> somthing like this, uclibc-ng is a directory including all patches: > >>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose > >>>>>> > >>>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages > >>>>> > >>>>> It only recreates uclibc-ng tarball. (or any git ones). > >>>> OK... I use git trees for binutils, gcc and linux ;( > >>>> > >>>>> You can do on a failure: > >>>>> cd openadk > >>>>> make v > >>>>> > >>>>> best regards > >>>>> Waldemar > >>>> > >>> > >> > > > > _______________________________________________ > > devel mailing list > > devel@uclibc-ng.org > > https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel >
Hi, > Am 30.07.2018 um 15:50 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > >> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >> >> Hi, >> >> the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling. >> >> Can be seen with --test=libc in embedded-test.sh. > > It looks like tests are looping with getty error messages, is that what you saw? Yes. >> So there is still some regression for arm and ELF. >> >> Any idea? > Not yet. > > How can I run embedded-test.sh twice with different uclibc-ng version? > (the original one, and the one with my patches) > Should I restart from a new directory? exactly. best regards Waldemar > >> best regards >> Waldemar >> >>> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>: >>> >>> Hi, >>> >>> sorry for the confusion. >>> I take care about the last failure. >>> The build runs further so, I give you feedback once it is finished. >>> >>> I can squash the patch before pushing, >>> >>> best regards >>> Waldemar >>> >>>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>>>> >>>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> okay, that was already the next test >>>>> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. >>>> I'm not sure to understand; if by "now" you mean with my uclibc-ng >>>> patch series, then no. At least not yet. >>>> As said in the cover letter this patch series supports only armv7. And >>>> as noticed by Thomas, it doesn't yet support armv7m. >>>> The plan is definitely to support armv7m. >>>> >>>> So you probably want to create a new config armv7-nommu-arm in your script. >>>> >>>> Since I'm not familiar with this script nor openadk, I don't know what >>>> this implies. >>>> >>>> I thought you wanted to first make sure my uclibc-ng patch series >>>> didn't break existing configs. >>>> >>>> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC >>>> patches (see link in cover letter). You also need recent binutils. I >>>> don't know if/how your script handles that since I noticed "7.3.0" in >>>> the GCC error messages you shared, which seems to indicate you are not >>>> using the most recent GCC. >>>> >>>> And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. >>>> This will configure GCC is the right mode, no need to use flags such as -mfdpic. >>>> >>>> >>>>> Will you sent a complete patch with sob for the previous error? >>>> Which previous error? If you mean the latest you reported involving >>>> -mfdpic, then I hope my answer just above clarifies. >>>> >>>> If you mean the broken armv5 build, then yes, but the patch I sent >>>> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC >>>> code for arm" >>>> >>>> What the practice on this list? Shall I send v2 of patch 4/32 asap, on >>>> rather wait for feedback on other patches and then send a v2 of the >>>> whole series? >>>> >>>> Thanks, >>>> >>>> Christophe >>>> >>>> >>>>> best regards >>>>> >>>>> Waldemar >>>>> >>>>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>>>>> >>>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb >>>>>> <mail@waldemar-brodkorb.de> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> Christophe Lyon wrote, >>>>>>> >>>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Christophe Lyon wrote, >>>>>>>>> >>>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Christophe, >>>>>>>>>>> Waldemar Brodkorb wrote, >>>>>>>>>>> >>>>>>>>>>>> Hi Christophe, >>>>>>>>>>>> >>>>>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error >>>>>>>>>>> log. You can check with embedded-test.sh if you like. >>>>>>>>>>> >>>>>>>>>>> Any idea? All patches appliend on top of master, >>>>>>>>>> >>>>>>>>>> Thanks for testing this configuration. >>>>>>>>>> >>>>>>>>>> I left FDPIC-only code activated unconditionally. >>>>>>>>>> >>>>>>>>>> Can you try the attached small patch? >>>>>>>>> >>>>>>>>> Even fixing this small typo in #endf it errors out. >>>>>>>>> >>>>>>>> OK, here is an updated version of the previous patch. >>>>>>> >>>>>>> Works for the ldso, but I think we need a symbol to differentiate >>>>>>> between ELF and FDPIC. >>>>>>> See attached error. >>>>>> >>>>>> Strange, the build succeeded for me. I don't understand where this >>>>>> -mfdpic option comes from? >>>>>> It is not part of the patches I sent, unless I'm mistaken: it would be >>>>>> "embedded" in GCC if configured for FDPIC, which is not the case in >>>>>> this build for armv5. >>>>>> >>>>>> >>>>>>> >>>>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know >>>>>>>>>> about this script, I have used armv5 as arch, is it the one you meant? >>>>>>>>> >>>>>>>>> somthing like this, uclibc-ng is a directory including all patches: >>>>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose >>>>>>>> >>>>>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages >>>>>>> >>>>>>> It only recreates uclibc-ng tarball. (or any git ones). >>>>>> OK... I use git trees for binutils, gcc and linux ;( >>>>>> >>>>>>> You can do on a failure: >>>>>>> cd openadk >>>>>>> make v >>>>>>> >>>>>>> best regards >>>>>>> Waldemar >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@uclibc-ng.org >>> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel >> >
On Tue, 31 Jul 2018 at 14:58, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > Hi, > > > Am 30.07.2018 um 15:50 schrieb Christophe Lyon < > christophe.lyon@linaro.org>: > > > >> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> > wrote: > >> > >> Hi, > >> > >> the toolchain tests are finished successfully, but the armv5 runtime > tests showing some problems with getty and argv handling. > >> > >> Can be seen with --test=libc in embedded-test.sh. > > > > It looks like tests are looping with getty error messages, is that what > you saw? > > Yes. > > >> So there is still some regression for arm and ELF. > >> > >> Any idea? > > Not yet. > > > > How can I run embedded-test.sh twice with different uclibc-ng version? > > (the original one, and the one with my patches) > > Should I restart from a new directory? > > exactly. > > Too bad, It's taking ages to regenerate the gcc and linux tarballs from the git trees I provide (I saw tar+xz taking ~30 minutes during a 50 minutes full run of the script) I wish I could run: embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --test=libc embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --libc-source=UUU --libc-version=fdpic --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --verbose --test=libc where the 2nd step would only build the new version of uclibc-ng and run the corresponding tests. > best regards > Waldemar > > > >> best regards > >> Waldemar > >> > >>> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>: > >>> > >>> Hi, > >>> > >>> sorry for the confusion. > >>> I take care about the last failure. > >>> The build runs further so, I give you feedback once it is finished. > >>> > >>> I can squash the patch before pushing, > >>> > >>> best regards > >>> Waldemar > >>> > >>>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon < > christophe.lyon@linaro.org>: > >>>>> > >>>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> > wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> okay, that was already the next test > >>>>> armv5-nommu-arm, which OpenADK needs to learn, as the default is > fdpic now. > >>>> I'm not sure to understand; if by "now" you mean with my uclibc-ng > >>>> patch series, then no. At least not yet. > >>>> As said in the cover letter this patch series supports only armv7. And > >>>> as noticed by Thomas, it doesn't yet support armv7m. > >>>> The plan is definitely to support armv7m. > >>>> > >>>> So you probably want to create a new config armv7-nommu-arm in your > script. > >>>> > >>>> Since I'm not familiar with this script nor openadk, I don't know what > >>>> this implies. > >>>> > >>>> I thought you wanted to first make sure my uclibc-ng patch series > >>>> didn't break existing configs. > >>>> > >>>> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC > >>>> patches (see link in cover letter). You also need recent binutils. I > >>>> don't know if/how your script handles that since I noticed "7.3.0" in > >>>> the GCC error messages you shared, which seems to indicate you are not > >>>> using the most recent GCC. > >>>> > >>>> And also note that the GCC/binutils target name is > arm-uclinuxfdpiceabi. > >>>> This will configure GCC is the right mode, no need to use flags such > as -mfdpic. > >>>> > >>>> > >>>>> Will you sent a complete patch with sob for the previous error? > >>>> Which previous error? If you mean the latest you reported involving > >>>> -mfdpic, then I hope my answer just above clarifies. > >>>> > >>>> If you mean the broken armv5 build, then yes, but the patch I sent > >>>> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC > >>>> code for arm" > >>>> > >>>> What the practice on this list? Shall I send v2 of patch 4/32 asap, on > >>>> rather wait for feedback on other patches and then send a v2 of the > >>>> whole series? > >>>> > >>>> Thanks, > >>>> > >>>> Christophe > >>>> > >>>> > >>>>> best regards > >>>>> > >>>>> Waldemar > >>>>> > >>>>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon < > christophe.lyon@linaro.org>: > >>>>>> > >>>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb > >>>>>> <mail@waldemar-brodkorb.de> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> Christophe Lyon wrote, > >>>>>>> > >>>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb < > wbx@uclibc-ng.org> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> Christophe Lyon wrote, > >>>>>>>>> > >>>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb < > wbx@uclibc-ng.org> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Christophe, > >>>>>>>>>>> Waldemar Brodkorb wrote, > >>>>>>>>>>> > >>>>>>>>>>>> Hi Christophe, > >>>>>>>>>>>> > >>>>>>>>>>>> i am doing a large testrun for the global changes and > hopefully push on monday or at least have some news. i am afk atm with just > little access to a computer. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached > error > >>>>>>>>>>> log. You can check with embedded-test.sh if you like. > >>>>>>>>>>> > >>>>>>>>>>> Any idea? All patches appliend on top of master, > >>>>>>>>>> > >>>>>>>>>> Thanks for testing this configuration. > >>>>>>>>>> > >>>>>>>>>> I left FDPIC-only code activated unconditionally. > >>>>>>>>>> > >>>>>>>>>> Can you try the attached small patch? > >>>>>>>>> > >>>>>>>>> Even fixing this small typo in #endf it errors out. > >>>>>>>>> > >>>>>>>> OK, here is an updated version of the previous patch. > >>>>>>> > >>>>>>> Works for the ldso, but I think we need a symbol to differentiate > >>>>>>> between ELF and FDPIC. > >>>>>>> See attached error. > >>>>>> > >>>>>> Strange, the build succeeded for me. I don't understand where this > >>>>>> -mfdpic option comes from? > >>>>>> It is not part of the patches I sent, unless I'm mistaken: it would > be > >>>>>> "embedded" in GCC if configured for FDPIC, which is not the case in > >>>>>> this build for armv5. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't > know > >>>>>>>>>> about this script, I have used armv5 as arch, is it the one you > meant? > >>>>>>>>> > >>>>>>>>> somthing like this, uclibc-ng is a directory including all > patches: > >>>>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng > --arch=armv5 --verbose > >>>>>>>> > >>>>>>>> Is there a way to avoid (re)creating all the source tarballs? > It's taking ages > >>>>>>> > >>>>>>> It only recreates uclibc-ng tarball. (or any git ones). > >>>>>> OK... I use git trees for binutils, gcc and linux ;( > >>>>>> > >>>>>>> You can do on a failure: > >>>>>>> cd openadk > >>>>>>> make v > >>>>>>> > >>>>>>> best regards > >>>>>>> Waldemar > >>>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> devel@uclibc-ng.org > >>> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel > >> > > > > <div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 31 Jul 2018 at 14:58, Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org">wbx@uclibc-ng.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> > Am 30.07.2018 um 15:50 schrieb Christophe Lyon <<a href="mailto:christophe.lyon@linaro.org" target="_blank">christophe.lyon@linaro.org</a>>:<br> > <br> >> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org" target="_blank">wbx@uclibc-ng.org</a>> wrote:<br> >> <br> >> Hi,<br> >> <br> >> the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling.<br> >> <br> >> Can be seen with --test=libc in embedded-test.sh.<br> > <br> > It looks like tests are looping with getty error messages, is that what you saw?<br> <br> Yes.<br> <br> >> So there is still some regression for arm and ELF.<br> >> <br> >> Any idea?<br> > Not yet.<br> > <br> > How can I run embedded-test.sh twice with different uclibc-ng version?<br> > (the original one, and the one with my patches)<br> > Should I restart from a new directory?<br> <br> exactly.<br> <br></blockquote><div>Too bad, It's taking ages to regenerate the gcc and linux tarballs from the git trees I provide (I saw tar+xz taking ~30 minutes during a 50 minutes full run of the script)</div><div><br></div><div>I wish I could run:</div><div>embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --test=libc<br></div><div><div>embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --libc-source=UUU --libc-version=fdpic --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --verbose --test=libc</div></div><div>where the 2nd step would only build the new version of uclibc-ng and run the corresponding tests.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> best regards<br> Waldemar<br> > <br> >> best regards<br> >> Waldemar<br> >> <br> >>> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org" target="_blank">wbx@uclibc-ng.org</a>>:<br> >>> <br> >>> Hi,<br> >>> <br> >>> sorry for the confusion.<br> >>> I take care about the last failure.<br> >>> The build runs further so, I give you feedback once it is finished.<br> >>> <br> >>> I can squash the patch before pushing,<br> >>> <br> >>> best regards<br> >>> Waldemar<br> >>> <br> >>>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <<a href="mailto:christophe.lyon@linaro.org" target="_blank">christophe.lyon@linaro.org</a>>:<br> >>>>> <br> >>>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org" target="_blank">wbx@uclibc-ng.org</a>> wrote:<br> >>>>> <br> >>>>> Hi,<br> >>>>> <br> >>>>> okay, that was already the next test<br> >>>>> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now.<br> >>>> I'm not sure to understand; if by "now" you mean with my uclibc-ng<br> >>>> patch series, then no. At least not yet.<br> >>>> As said in the cover letter this patch series supports only armv7. And<br> >>>> as noticed by Thomas, it doesn't yet support armv7m.<br> >>>> The plan is definitely to support armv7m.<br> >>>> <br> >>>> So you probably want to create a new config armv7-nommu-arm in your script.<br> >>>> <br> >>>> Since I'm not familiar with this script nor openadk, I don't know what<br> >>>> this implies.<br> >>>> <br> >>>> I thought you wanted to first make sure my uclibc-ng patch series<br> >>>> didn't break existing configs.<br> >>>> <br> >>>> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC<br> >>>> patches (see link in cover letter). You also need recent binutils. I<br> >>>> don't know if/how your script handles that since I noticed "7.3.0" in<br> >>>> the GCC error messages you shared, which seems to indicate you are not<br> >>>> using the most recent GCC.<br> >>>> <br> >>>> And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi.<br> >>>> This will configure GCC is the right mode, no need to use flags such as -mfdpic.<br> >>>> <br> >>>> <br> >>>>> Will you sent a complete patch with sob for the previous error?<br> >>>> Which previous error? If you mean the latest you reported involving<br> >>>> -mfdpic, then I hope my answer just above clarifies.<br> >>>> <br> >>>> If you mean the broken armv5 build, then yes, but the patch I sent<br> >>>> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC<br> >>>> code for arm"<br> >>>> <br> >>>> What the practice on this list? Shall I send v2 of patch 4/32 asap, on<br> >>>> rather wait for feedback on other patches and then send a v2 of the<br> >>>> whole series?<br> >>>> <br> >>>> Thanks,<br> >>>> <br> >>>> Christophe<br> >>>> <br> >>>> <br> >>>>> best regards<br> >>>>> <br> >>>>> Waldemar<br> >>>>> <br> >>>>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <<a href="mailto:christophe.lyon@linaro.org" target="_blank">christophe.lyon@linaro.org</a>>:<br> >>>>>> <br> >>>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb<br> >>>>>> <<a href="mailto:mail@waldemar-brodkorb.de" target="_blank">mail@waldemar-brodkorb.de</a>> wrote:<br> >>>>>>> <br> >>>>>>> Hi,<br> >>>>>>> Christophe Lyon wrote,<br> >>>>>>> <br> >>>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org" target="_blank">wbx@uclibc-ng.org</a>> wrote:<br> >>>>>>>>> <br> >>>>>>>>> Hi,<br> >>>>>>>>> Christophe Lyon wrote,<br> >>>>>>>>> <br> >>>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <<a href="mailto:wbx@uclibc-ng.org" target="_blank">wbx@uclibc-ng.org</a>> wrote:<br> >>>>>>>>>>> <br> >>>>>>>>>>> Hi Christophe,<br> >>>>>>>>>>> Waldemar Brodkorb wrote,<br> >>>>>>>>>>> <br> >>>>>>>>>>>> Hi Christophe,<br> >>>>>>>>>>>> <br> >>>>>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer.<br> >>>>>>>>>>>> <br> >>>>>>>>>>> <br> >>>>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error<br> >>>>>>>>>>> log. You can check with embedded-test.sh if you like.<br> >>>>>>>>>>> <br> >>>>>>>>>>> Any idea? All patches appliend on top of master,<br> >>>>>>>>>> <br> >>>>>>>>>> Thanks for testing this configuration.<br> >>>>>>>>>> <br> >>>>>>>>>> I left FDPIC-only code activated unconditionally.<br> >>>>>>>>>> <br> >>>>>>>>>> Can you try the attached small patch?<br> >>>>>>>>> <br> >>>>>>>>> Even fixing this small typo in #endf it errors out.<br> >>>>>>>>> <br> >>>>>>>> OK, here is an updated version of the previous patch.<br> >>>>>>> <br> >>>>>>> Works for the ldso, but I think we need a symbol to differentiate<br> >>>>>>> between ELF and FDPIC.<br> >>>>>>> See attached error.<br> >>>>>> <br> >>>>>> Strange, the build succeeded for me. I don't understand where this<br> >>>>>> -mfdpic option comes from?<br> >>>>>> It is not part of the patches I sent, unless I'm mistaken: it would be<br> >>>>>> "embedded" in GCC if configured for FDPIC, which is not the case in<br> >>>>>> this build for armv5.<br> >>>>>> <br> >>>>>> <br> >>>>>>> <br> >>>>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know<br> >>>>>>>>>> about this script, I have used armv5 as arch, is it the one you meant?<br> >>>>>>>>> <br> >>>>>>>>> somthing like this, uclibc-ng is a directory including all patches:<br> >>>>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose<br> >>>>>>>> <br> >>>>>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages<br> >>>>>>> <br> >>>>>>> It only recreates uclibc-ng tarball. (or any git ones).<br> >>>>>> OK... I use git trees for binutils, gcc and linux ;(<br> >>>>>> <br> >>>>>>> You can do on a failure:<br> >>>>>>> cd openadk<br> >>>>>>> make v<br> >>>>>>> <br> >>>>>>> best regards<br> >>>>>>> Waldemar<br> >>>>>> <br> >>>>> <br> >>>> <br> >>> <br> >>> _______________________________________________<br> >>> devel mailing list<br> >>> <a href="mailto:devel@uclibc-ng.org" target="_blank">devel@uclibc-ng.org</a><br> >>> <a href="https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel</a><br> >> <br> > <br> <br> </blockquote></div></div>
On 31/07/2018 14:58, Waldemar Brodkorb wrote: > Hi, > >> Am 30.07.2018 um 15:50 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >> >>> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>> >>> Hi, >>> >>> the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling. >>> >>> Can be seen with --test=libc in embedded-test.sh. >> It looks like tests are looping with getty error messages, is that what you saw? > Yes. I have just posted version 2 of patches 4, 8 and 11. I fixed them in such a way that they do not introduce regressions when FDPIC is not activated (embedded-test.sh --arch=armv5) I guess the next step would be to add a new configuration to embedded-test.sh/openadk, such as "armv7_fdpic" that would exercise FDPIC in ARM mode. As mentioned earlier, this requires recent binutils, GCC trunk+patches and using the right target name: arm-uclinuxfdpiceabi How easy is it to add such a config in openadk? Thanks, Christophe >>> So there is still some regression for arm and ELF. >>> >>> Any idea? >> Not yet. >> >> How can I run embedded-test.sh twice with different uclibc-ng version? >> (the original one, and the one with my patches) >> Should I restart from a new directory? > exactly. > > best regards > Waldemar >>> best regards >>> Waldemar >>> >>>> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>: >>>> >>>> Hi, >>>> >>>> sorry for the confusion. >>>> I take care about the last failure. >>>> The build runs further so, I give you feedback once it is finished. >>>> >>>> I can squash the patch before pushing, >>>> >>>> best regards >>>> Waldemar >>>> >>>>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>>>>> >>>>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> okay, that was already the next test >>>>>> armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now. >>>>> I'm not sure to understand; if by "now" you mean with my uclibc-ng >>>>> patch series, then no. At least not yet. >>>>> As said in the cover letter this patch series supports only armv7. And >>>>> as noticed by Thomas, it doesn't yet support armv7m. >>>>> The plan is definitely to support armv7m. >>>>> >>>>> So you probably want to create a new config armv7-nommu-arm in your script. >>>>> >>>>> Since I'm not familiar with this script nor openadk, I don't know what >>>>> this implies. >>>>> >>>>> I thought you wanted to first make sure my uclibc-ng patch series >>>>> didn't break existing configs. >>>>> >>>>> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC >>>>> patches (see link in cover letter). You also need recent binutils. I >>>>> don't know if/how your script handles that since I noticed "7.3.0" in >>>>> the GCC error messages you shared, which seems to indicate you are not >>>>> using the most recent GCC. >>>>> >>>>> And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi. >>>>> This will configure GCC is the right mode, no need to use flags such as -mfdpic. >>>>> >>>>> >>>>>> Will you sent a complete patch with sob for the previous error? >>>>> Which previous error? If you mean the latest you reported involving >>>>> -mfdpic, then I hope my answer just above clarifies. >>>>> >>>>> If you mean the broken armv5 build, then yes, but the patch I sent >>>>> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC >>>>> code for arm" >>>>> >>>>> What the practice on this list? Shall I send v2 of patch 4/32 asap, on >>>>> rather wait for feedback on other patches and then send a v2 of the >>>>> whole series? >>>>> >>>>> Thanks, >>>>> >>>>> Christophe >>>>> >>>>> >>>>>> best regards >>>>>> >>>>>> Waldemar >>>>>> >>>>>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <christophe.lyon@linaro.org>: >>>>>>> >>>>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb >>>>>>> <mail@waldemar-brodkorb.de> wrote: >>>>>>>> Hi, >>>>>>>> Christophe Lyon wrote, >>>>>>>> >>>>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> Christophe Lyon wrote, >>>>>>>>>> >>>>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Christophe, >>>>>>>>>>>> Waldemar Brodkorb wrote, >>>>>>>>>>>> >>>>>>>>>>>>> Hi Christophe, >>>>>>>>>>>>> >>>>>>>>>>>>> i am doing a large testrun for the global changes and hopefully push on monday or at least have some news. i am afk atm with just little access to a computer. >>>>>>>>>>>>> >>>>>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error >>>>>>>>>>>> log. You can check with embedded-test.sh if you like. >>>>>>>>>>>> >>>>>>>>>>>> Any idea? All patches appliend on top of master, >>>>>>>>>>> Thanks for testing this configuration. >>>>>>>>>>> >>>>>>>>>>> I left FDPIC-only code activated unconditionally. >>>>>>>>>>> >>>>>>>>>>> Can you try the attached small patch? >>>>>>>>>> Even fixing this small typo in #endf it errors out. >>>>>>>>>> >>>>>>>>> OK, here is an updated version of the previous patch. >>>>>>>> Works for the ldso, but I think we need a symbol to differentiate >>>>>>>> between ELF and FDPIC. >>>>>>>> See attached error. >>>>>>> Strange, the build succeeded for me. I don't understand where this >>>>>>> -mfdpic option comes from? >>>>>>> It is not part of the patches I sent, unless I'm mistaken: it would be >>>>>>> "embedded" in GCC if configured for FDPIC, which is not the case in >>>>>>> this build for armv5. >>>>>>> >>>>>>> >>>>>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't know >>>>>>>>>>> about this script, I have used armv5 as arch, is it the one you meant? >>>>>>>>>> somthing like this, uclibc-ng is a directory including all patches: >>>>>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5 --verbose >>>>>>>>> Is there a way to avoid (re)creating all the source tarballs? It's taking ages >>>>>>>> It only recreates uclibc-ng tarball. (or any git ones). >>>>>>> OK... I use git trees for binutils, gcc and linux ;( >>>>>>> >>>>>>>> You can do on a failure: >>>>>>>> cd openadk >>>>>>>> make v >>>>>>>> >>>>>>>> best regards >>>>>>>> Waldemar >>>> _______________________________________________ >>>> devel mailing list >>>> devel@uclibc-ng.org >>>> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@uclibc-ng.org > https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
Hi, Christophe Lyon wrote, > On 31/07/2018 14:58, Waldemar Brodkorb wrote: > >Hi, > > > >>Am 30.07.2018 um 15:50 schrieb Christophe Lyon <christophe.lyon@linaro.org>: > >> > >>>On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote: > >>> > >>>Hi, > >>> > >>>the toolchain tests are finished successfully, but the armv5 runtime tests showing some problems with getty and argv handling. > >>> > >>>Can be seen with --test=libc in embedded-test.sh. > >>It looks like tests are looping with getty error messages, is that what you saw? > >Yes. > > I have just posted version 2 of patches 4, 8 and 11. I fixed them in such a way that they do not introduce regressions when FDPIC is not activated (embedded-test.sh --arch=armv5) > > I guess the next step would be to add a new configuration to embedded-test.sh/openadk, such as "armv7_fdpic" that would exercise FDPIC in ARM mode. As mentioned earlier, this requires recent binutils, GCC trunk+patches and using the right target name: arm-uclinuxfdpiceabi > > How easy is it to add such a config in openadk? Depends, I will start adding something like that, so you can concentrate in gcc upstreaming. The patch series is pushed, thanks. Waldemar
Hello, This patch series implements the uClibc-ng contribution of the FDPIC ABI for ARM targets. This ABI enables to run Linux on ARM MMU-less cores and supports shared libraries to reduce the memory footprint. Without MMU, text and data segments relative distances are different from one process to another, hence the need for a dedicated FDPIC register holding the start address of the data segment. One of the side effects is that function pointers require two words to be represented: the address of the code, and the data segment start address. These two words are designated as "Function Descriptor", hence the "FD PIC" name. On ARM, the FDPIC register is r9 [1], and the target name is arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another ABI and the BFLAT file format; it does not support code sharing. This work was developed some time ago by STMicroelectronics, and was presented during Linaro Connect SFO15 (September 2015). You can watch the discussion and read the slides [2]. This presentation was related to the toolchain published on github [3], which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1 and qemu-2.3.0, and for which pre-built binaries are available [3]. The ABI itself is described in details in [1]. Our Linux kernel patches have been updated and committed by Nicolas Pitre (Linaro) in July 2017. They are required so that the loader is able to handle this new file type. Indeed, the ELF files are tagged with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as well as the new relocations involved. The binutils and QEMU patch series have been merged recently. [4][5] The GCC patch series has been submitted and is under discussion. [6] This patch series consists in the original uClibc-based patches, which I have rebased and updated for uClibc-ng. Most of them are strictly related to FDPIC on ARM, while a few others address generic issues. Are the uClibc-ng patches OK for inclusion in master? Thanks, Christophe. [1] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt [2] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ [3] https://github.com/mickael-guene/fdpic_manifest [4] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f1ac0afe481e83c9a33f247b81fa7de789edc4d9 [5] https://git.qemu.org/?p=qemu.git;a=commit;h=e8fa72957419c11984608062c7dcb204a6003a06 [6] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01439.html Christophe Lyon (32): [ARM][FDPIC] Allow to select FDPIC ELF for arm architecture [FDPIC] rtld: Do not protect RELRO segments when we don't use an MMU. [ARM][FDPIC] rtld: Add #if defined (__FDPIC__) [ARM][FDPIC] rtld: Add FDPIC code for arm [ARM][FDPIC] rtld: Avoid FUNCDESC relocation on _start [ARM][FDPIC] rtld: Add startup code [ARM] Fix bug in _dl_pread when using pread64 syscall [ARM][FDPIC] Add application startup code for FDPIC [ARM][FDPIC] Add runtime support needed for C++ exceptions [ARM][FDPIC] Allow to generate PIE 'static' binary [ARM][FDPIC] rtld: Add lazy binding support [ARM][FDPIC] TLS: fix relocation computation [ARM][FDPIC] rtld: Compile with -fno-unwind-tables -fno-asynchronous-unwind-tables [ARM][FDPIC] arm/clone.S: Fix threading support [ARM][FDPIC] enable NPTL on TARGET_arm [ARM][FDPIC] rtld: Use ELF_RTYPE_CLASS_DLSYM [FDPIC] rtld: Initialize _dl_error_catch_tsd without FUNCDESC relocation [FDPIC] nptl: disable mprotect usage in stack protection [FDPIC] nptl: Disable fork and atfork on MMU-less systems. [FDPIC] nptl: Do not use madvise [ARM][FDPIC] nptl: Use linker-defined symbol to find start of .tdata section. [FDPIC] nptl: Allow sem_open to work on MMU-less systems [FDPIC] nptl: Add pthread_mutex_getprioceiling and pthread_mutex_setprioceiling support [FDPIC] nptl: Use vfork on MMU-less for system() nptl: Clear TLS area for static binaries. [FDPIC] nptl: Replace sbrk with mmap nptl threads: Fix bug in using a weak variable. Fix htab_delete loop counter isnan: Add isnan weak alias to __isnan mbtowc: Fix non compliant behavior for end of string Fix shm_open posix compliance error code [ARM] rtld: Avoid crash on R_ARM_NONE relocation extra/Configs/Config.in | 2 +- extra/Configs/Config.in.arch | 2 +- include/elf.h | 2 + include/link.h | 6 +- ldso/include/dl-elf.h | 2 +- ldso/include/dl-hash.h | 2 +- ldso/include/dl-string.h | 3 +- ldso/include/dl-syscall.h | 13 +- ldso/include/inline-hashtab.h | 2 +- ldso/ldso/Makefile.in | 2 - ldso/ldso/arm/dl-inlines.h | 1 + ldso/ldso/arm/dl-startup.h | 112 +++++++++++++- ldso/ldso/arm/dl-sysdep.h | 63 ++++++-- ldso/ldso/arm/elfinterp.c | 166 +++++++++++++++++---- ldso/ldso/arm/resolve.S | 23 +++ ldso/ldso/dl-elf.c | 6 +- ldso/ldso/dl-hash.c | 4 +- ldso/ldso/dl-tls.c | 1 + ldso/ldso/fdpic/dl-inlines.h | 2 + ldso/ldso/fdpic/dl-sysdep.h | 2 +- ldso/ldso/ldso.c | 23 ++- libc/misc/elf/dl-iterate-phdr.c | 2 +- libc/misc/internals/__uClibc_main.c | 47 +++++- libc/stdlib/stdlib.c | 6 +- libc/stdlib/system.c | 5 + libc/sysdeps/linux/arm/Makefile.arch | 2 +- libc/sysdeps/linux/arm/bits/elf-fdpic.h | 114 ++++++++++++++ libc/sysdeps/linux/arm/clone.S | 12 ++ libc/sysdeps/linux/arm/crt1.S | 66 ++++++++ libc/sysdeps/linux/arm/crtreloc.c | 144 ++++++++++++++++++ libc/sysdeps/linux/arm/find_exidx.c | 38 +++++ libc/sysdeps/linux/arm/find_got.c | 72 +++++++++ libm/s_isnan.c | 1 + libpthread/nptl/Makefile.in | 1 - libpthread/nptl/allocatestack.c | 6 + libpthread/nptl/linux_fsinfo.h | 5 +- libpthread/nptl/pthread_create.c | 4 + libpthread/nptl/sem_open.c | 8 +- libpthread/nptl/sysdeps/generic/libc-tls.c | 27 +++- libpthread/nptl/sysdeps/unix/sysv/linux/fork.c | 3 + .../sysdeps/unix/sysv/linux/libc_pthread_init.c | 4 + .../nptl/sysdeps/unix/sysv/linux/register-atfork.c | 14 +- .../sysdeps/unix/sysv/linux/unregister-atfork.c | 10 +- librt/shm.c | 3 + 44 files changed, 958 insertions(+), 75 deletions(-) create mode 100644 ldso/ldso/arm/dl-inlines.h create mode 100644 libc/sysdeps/linux/arm/bits/elf-fdpic.h create mode 100644 libc/sysdeps/linux/arm/crtreloc.c create mode 100644 libc/sysdeps/linux/arm/find_got.c