RE: [Weekly] 17-21 FEB 2013
> -Original Message- > From: linaro-toolchain-boun...@lists.linaro.org [mailto:linaro- > toolchain-boun...@lists.linaro.org] On Behalf Of Wookey > Sent: 23 February 2014 20:43 > To: Rob Savoye > Cc: Linaro ToolChain > Subject: Re: [Weekly] 17-21 FEB 2013 > > +++ Rob Savoye [2014-02-23 08:05 -0700]: > > On 02/23/2014 03:09 AM, Alex Bennée wrote: > > > Is this a problem with the emulated shared libraries not loading > (qemu > > > itself should be static)? Wookey did find a problem when built on > older > > > distros as the kernel version (CONFIG_UNAME) passed to the emulated > > > system cause libc to get confused as older kernels don't support > aarch64! > > > > Ah... It works fine on Ubuntu saucy, but not on Ubuntu precise, > which > > is what the build farm machine run. Is there a workaround short of > > upgrading all the TCWG build machines ? > > > > > Debian is carrying a patch that forces the kernel version to be > reported > > > to libc as 3.8. > > Is this a kernel patch or q qemu patch ? > > There is an ubuntu qemu patch which reports later uname on aarch64 > (below). But it turns out that if you build qemu_without_ the configure > option --enable-uname-release then the ubuntu patch is no longer needed > as qemu itself now DTRT (reporting an appropriate minimum uname version > on a per-arch basis). Can you not achieve the same thing with the -r option on the command line ? i.e. qemu-aarch64 -r 3.7.0 ? Also achievable by : set_board_info sim,options " -r 3.7.0" in your boards file. Ramana > > This was the ubuntu patch to force this: > > Index: qemu-1.7.50+dfsg/linux-user/main.c > === > --- qemu-1.7.50+dfsg.orig/linux-user/main.c 2014-02-17 > 15:25:03.0 + > +++ qemu-1.7.50+dfsg/linux-user/main.c2014-02-18 16:23:10.340055485 > + > @@ -69,7 +69,15 @@ > static void usage(void); > > static const char *interp_prefix = CONFIG_QEMU_INTERP_PREFIX; > -const char *qemu_uname_release = CONFIG_UNAME_RELEASE; > + > +/* arm64 glibc requires a kernel with arm64 support. Qemu needs to > report one. */ > +#ifdef TARGET_AARCH64 > +# define UNAME_RELEASE "3.7.0" > +#else > +# define UNAME_RELEASE CONFIG_UNAME_RELEASE > +#endif > + > +const char *qemu_uname_release = UNAME_RELEASE; > > /* XXX: on x86 MAP_GROWSDOWN only works if ESP <= address + 32, so > we allocate a bigger stack. Need a better solution, for example > > Wookey > -- > Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM > http://wookware.org/ > > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week 8
== Issues == * none == Progress == * LRA on AArch32: o TCWG-343 : Make LRA the default for the ARM backend (0/10) - No progress this week on my side. o TCWG-345 : Analyse performance of LRA for ARM. (4/10) - Analysed Spec2K figures on Cortex-a15. * Backports review: (1/10) o Start to look at the Gerrit review process. o Lack of testsuite results * Misc: o LCA'14 : AArch64 toolchain status session. (3/10) o Various meetings. (2/10) == Next == * Backports review * https://bugs.launchpad.net/bugs/1169164 * Connect ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
+++ Ramana Radhakrishnan [2014-02-24 09:08 +]: > From: linaro-toolchain-boun...@lists.linaro.org [mailto:linaro- > > toolchain-boun...@lists.linaro.org] On Behalf Of Wookey > > Sent: 23 February 2014 20:43 > > To: Rob Savoye > > Cc: Linaro ToolChain > > Subject: Re: [Weekly] 17-21 FEB 2013 > > > > +++ Rob Savoye [2014-02-23 08:05 -0700]: > > > On 02/23/2014 03:09 AM, Alex Bennée wrote: > > > > Is this a problem with the emulated shared libraries not loading > > (qemu > > > > itself should be static)? Wookey did find a problem when built on > > older > > > > distros as the kernel version (CONFIG_UNAME) passed to the emulated > > > > system cause libc to get confused as older kernels don't support > > aarch64! > > > > > > Ah... It works fine on Ubuntu saucy, but not on Ubuntu precise, > > which > > > is what the build farm machine run. Is there a workaround short of > > > upgrading all the TCWG build machines ? > > > > > > > Debian is carrying a patch that forces the kernel version to be > > reported > > > > to libc as 3.8. > > > Is this a kernel patch or q qemu patch ? > > > > There is an ubuntu qemu patch which reports later uname on aarch64 > > (below). But it turns out that if you build qemu_without_ the configure > > option --enable-uname-release then the ubuntu patch is no longer needed > > as qemu itself now DTRT (reporting an appropriate minimum uname version > > on a per-arch basis). > > Can you not achieve the same thing with the -r option on the command line ? > > i.e. qemu-aarch64 -r 3.7.0 ? > > Also achievable by : > > set_board_info sim,options " -r 3.7.0" > > in your boards file. Where does a 'boards' file go/come from? Yes, or setting QEMU_UNAME on the command line, but I don't see how those work well with the binfmt settings that simply give a binary to run when the kernel spots the relevant binary magic. There is no provision for options or env vars, and the whole thing is clearly going to work much better if the binary just DTRT. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 02/24/2014 07:15 AM, Wookey wrote: > Where does a 'boards' file go/come from? It's a DejaGnu config file, used for remote testing. > Yes, or setting QEMU_UNAME on the command line, but I don't see how > those work well with the binfmt settings that simply give a binary to > run when the kernel spots the relevant binary magic. There is no > provision for options or env vars, and the whole thing is clearly going > to work much better if the binary just DTRT. I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the executable name. What would I set QEMU_UNAME to ? I still having the problem finding the dynamic linker on an older distro. - rob - ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
+++ Rob Savoye [2014-02-24 07:54 -0700]: > On 02/24/2014 07:15 AM, Wookey wrote: > > Where does a 'boards' file go/come from? > It's a DejaGnu config file, used for remote testing. > > Yes, or setting QEMU_UNAME on the command line, but I don't see how > > those work well with the binfmt settings that simply give a binary to > > run when the kernel spots the relevant binary magic. There is no > > provision for options or env vars, and the whole thing is clearly going > > to work much better if the binary just DTRT. > > I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the > executable name. What would I set QEMU_UNAME to ? QEMU_UNAME=3.8.0 But that only addresses the 'KERNEL TOO OLD' error. > I still having the > problem finding the dynamic linker on an older distro. I suspect this is a different problem. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 24 February 2014 14:54, Rob Savoye wrote: > On 02/24/2014 07:15 AM, Wookey wrote: >> Where does a 'boards' file go/come from? > It's a DejaGnu config file, used for remote testing. >> Yes, or setting QEMU_UNAME on the command line, but I don't see how >> those work well with the binfmt settings that simply give a binary to >> run when the kernel spots the relevant binary magic. There is no >> provision for options or env vars, and the whole thing is clearly going >> to work much better if the binary just DTRT. > > I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the > executable name. What would I set QEMU_UNAME to ? If you're using qemu master you shouldn't need to set it to anything. It's an emergency-use mechanism in case a future newer glibc wants an even newer kernel, but it shouldn't be necessary right now, because qemu will automatically force the reported kernel version to at least 3.8.0. I'm not sure where the Ubuntu qemu patch came from (I didn't think Ubuntu were shipping any aarch64 qemu just yet) but it looks like part of the SuSE tree's workaround for this issue, which we fixed in a cleaner way upstream. thanks -- PMM ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 02/24/2014 08:10 AM, Peter Maydell wrote: > If you're using qemu master you shouldn't need to set it to > anything. It's an emergency-use mechanism in case a future > newer glibc wants an even newer kernel, but it shouldn't > be necessary right now, because qemu will automatically > force the reported kernel version to at least 3.8.0. I was using your branch. I switched to qemu master, but still get this problem: qemu-aarch64 -cpu any -R 0 ./builds/x86_64-unknown-linux-gnu/aarch64-linux-gnu/gcc.git~linaro-4.8-branch-stage2/gcc/testsuite/gfortran/select_type_14.exe /lib/ld-linux-aarch64.so.1: No such file or directory - rob - ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 24/02/2014 17:28, Rob Savoye wrote: On 02/24/2014 08:10 AM, Peter Maydell wrote: If you're using qemu master you shouldn't need to set it to anything. It's an emergency-use mechanism in case a future newer glibc wants an even newer kernel, but it shouldn't be necessary right now, because qemu will automatically force the reported kernel version to at least 3.8.0. I was using your branch. I switched to qemu master, but still get this problem: qemu-aarch64 -cpu any -R 0 ./builds/x86_64-unknown-linux-gnu/aarch64-linux-gnu/gcc.git~linaro-4.8-branch-stage2/gcc/testsuite/gfortran/select_type_14.exe /lib/ld-linux-aarch64.so.1: No such file or directory - rob - ah if your libs are in /lib64 then a ln -sr /lib64/ld-linux-aarch64.so.1 /lib may do the trick i bumped into this it seems that new bits [i have not been active on this for while] place libs in lib64 not the initial lib when i first built i had to add this symlink. glibc 2.19 / gcc 4.8.2 Greg ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 24 February 2014 15:28, Rob Savoye wrote: > On 02/24/2014 08:10 AM, Peter Maydell wrote: >> If you're using qemu master you shouldn't need to set it to >> anything. It's an emergency-use mechanism in case a future >> newer glibc wants an even newer kernel, but it shouldn't >> be necessary right now, because qemu will automatically >> force the reported kernel version to at least 3.8.0. > > I was using your branch. I switched to qemu master, but still get this > problem: > > qemu-aarch64 -cpu any -R 0 > ./builds/x86_64-unknown-linux-gnu/aarch64-linux-gnu/gcc.git~linaro-4.8-branch-stage2/gcc/testsuite/gfortran/select_type_14.exe > /lib/ld-linux-aarch64.so.1: No such file or directory Well, do you have the aarch64 dynamic linker in /lib/ld-linux-aarch64.so.1 ? If not, then we won't find it (since you aren't running in a chroot and you aren't using -L to specify a sysroot directory to look in). thanks -- PMM ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 02/24/2014 08:51 AM, Peter Maydell wrote: > Well, do you have the aarch64 dynamic linker in > /lib/ld-linux-aarch64.so.1 ? If not, then we won't > find it (since you aren't running in a chroot and > you aren't using -L to specify a sysroot directory > to look in). Yeah, I have as a symbolic link. I also tried using -L to point to the sysroot, no luck... Seems to work fine on my Saucy laptop, all my problems are on Precise. - rob - ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 24 February 2014 16:06, Rob Savoye wrote: > On 02/24/2014 08:51 AM, Peter Maydell wrote: >> Well, do you have the aarch64 dynamic linker in >> /lib/ld-linux-aarch64.so.1 ? If not, then we won't >> find it (since you aren't running in a chroot and >> you aren't using -L to specify a sysroot directory >> to look in). > Yeah, I have as a symbolic link. I also tried using -L to point to the > sysroot, no luck... Seems to work fine on my Saucy laptop, all my > problems are on Precise. That's very odd. Can you strace qemu (using the host strace) and mail me the output? thanks -- PMM ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Hi, On 2014-02-17 13:40:00 +, Alex Bennée wrote: > > After a solid few months of work the QEMU master branch [1] has now reached > instruction feature parity with the suse-1.6 [6] tree that a lot of people > have been using to build various aarch64 binaries. In addition to the > SUSE work we have fixed numerous edge cases and finished off classes of > instructions. All instructions have been verified with Peter's RISU > random instruction testing tool. I have also built and run many > packages as well as built gcc and passed most of the aarch64 specific tests. > > I've tested against the following aarch64 rootfs: > * SUSE [2] > * Debian [3] > * Ubuntu Saucy [4] I'm running Libav's test suite (https://fate.libav.org/?arch=aarch64&comment=qemu) using a Gentoo crossdev sysroot. > In my tree the remaining insns that the GCC aarch64 tests need to > implement are: > FRECPE > FRECPX > CLS (2 misc variant) > CLZ (2 misc variant) > FSQRT > FRINTZ > FCVTZS > > Which I'm currently working though now. However for most build tasks I > expect the instructions in master [1] will be enough. Qemu master is enough to pass the tests with libav built with gcc 4.8.2, clang 3.3 and 3.4 (clang 3.4 build only with -O1, it fails otherwise). > Feedback I'm interested in > == > > * Any instruction failure (please include the log line with the > unsupported message) Neon support is not complete enough to run the hand written neon assembler optimizations in libav. Currently failing on narrowing shifts. > * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness). Just as a note, qemu-arm64 from the suse tree didn't show any threading issues with the libav test suite while qemu-aarch64 from master failed with a probability of ~10% running the same binary. > Many thanks to the SUSE guys for getting the aarch64 train rolling. I > hope your happy with the final result ;-) I'm happy, qemu master runs the libav test suite around 30% faster. Thanks to everyone involved. Janne ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Weekly] 17-21 FEB 2013
On 24 February 2014 17:10, Peter Maydell wrote: > On 24 February 2014 14:54, Rob Savoye wrote: > > On 02/24/2014 07:15 AM, Wookey wrote: > >> Where does a 'boards' file go/come from? > > It's a DejaGnu config file, used for remote testing. > >> Yes, or setting QEMU_UNAME on the command line, but I don't see how > >> those work well with the binfmt settings that simply give a binary to > >> run when the kernel spots the relevant binary magic. There is no > >> provision for options or env vars, and the whole thing is clearly going > >> to work much better if the binary just DTRT. > > > > I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the > > executable name. What would I set QEMU_UNAME to ? > > If you're using qemu master you shouldn't need to set it to > anything. It's an emergency-use mechanism in case a future > newer glibc wants an even newer kernel, but it shouldn't > be necessary right now, because qemu will automatically > force the reported kernel version to at least 3.8.0. > I'm not sure where the Ubuntu qemu patch came from (I didn't > think Ubuntu were shipping any aarch64 qemu just yet) but > it looks like part of the SuSE tree's workaround for this > issue, which we fixed in a cleaner way upstream. > Ubuntu passes --enable-uname-release=2.6.32 for configure, which overrides the clean way in upstream. Now, instead of doing the sane thing (dropping the configure argument) or submitting a useful patch, the problem was just wallpapered over by adding another override-of-override hidden in packaging... That said, the overriding power of the configure flag against UNAME_MINIMUM_RELEASE is probably not very useful. We might want to drop the configure flag, and set an UNAME_MINIMUM_RELEASE for all targets. For people who still want to override, keep the enviroment variable setting available. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote: > Hi, Thanks to all involved for your work here! > After a solid few months of work the QEMU master branch [1] has now reached > instruction feature parity with the suse-1.6 [6] tree that a lot of people > have been using to build various aarch64 binaries. In addition to the > SUSE work we have fixed numerous edge cases and finished off classes of > instructions. All instructions have been verified with Peter's RISU > random instruction testing tool. I have also built and run many > packages as well as built gcc and passed most of the aarch64 specific tests. > > I've tested against the following aarch64 rootfs: > * SUSE [2] > * Debian [3] > * Ubuntu Saucy [4] fyi, I've been doing my testing with Ubuntu Trusty. > In my tree the remaining insns that the GCC aarch64 tests need to > implement are: > FRECPE > FRECPX > CLS (2 misc variant) > CLZ (2 misc variant) > FSQRT > FRINTZ > FCVTZS > > Which I'm currently working though now. However for most build tasks I > expect the instructions in master [1] will be enough. > > If you want the latest instructions working their way to mainline you > are free to use my tree [5] which currently has: > > * Additional NEON/SIMD instructions > * sendmsg syscall > * Improved helper scripts for setting up binfmt_misc > * The ability to set QEMU_LOG_FILENAME to /path/to/something-%d.log > - this is useful when tests are failing N-levels deep as %d is > replaced with the pid > > Feedback I'm interested in > == > > * Any instruction failure (please include the log line with the > unsupported message) > * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness). I'm not sure if this qualifies as generic QEMU threading flakiness or not. I've found a couple conditions that causes master to core dump fairly reliably, while the aarch64-1.6 branch seems to consistently work fine. 1) dh_fixperms is a script that commonly runs at the end of a package build. Its basically doing a `find | xargs chmod`. 2) debootstrap --second-stage This is used to configure an arm64 chroot that was built using debootstrap on a non-native host. It is basically invoking a bunch of shell scripts (postinst, etc). When it blows up, the stack consistently looks like this: Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e /debootstrap/debootstrap --second-stage'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, __dest=0x400082c330) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); (gdb) bt #0 0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, __dest=0x400082c330) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #1 stq_p (v=274886476624, ptr=0x400082c330) at /mnt/qemu.upstream/include/qemu/bswap.h:280 #2 stq_le_p (v=274886476624, ptr=0x400082c330) at /mnt/qemu.upstream/include/qemu/bswap.h:315 #3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 #4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 , info=info@entry=0x0, set=set@entry=0x7fff62ae3530, env=env@entry=0x62d9c678) at /mnt/qemu.upstream/linux-user/signal.c:1286 #5 0x60059f46 in setup_frame (env=0x62d9c678, set=0x7fff62ae3530, ka=0x604ec1e0 , sig=17) at /mnt/qemu.upstream/linux-user/signal.c:1322 #6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at /mnt/qemu.upstream/linux-user/signal.c:5747 #7 0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at /mnt/qemu.upstream/linux-user/main.c:1082 #8 0x60005079 in main (argc=, argv=, envp=) at /mnt/qemu.upstream/linux-user/main.c:4374 There are some pretty large differences between these trees with respect to signal syscalls - is that the likely culprit? -dann > If you need to catch me in real time I'm available on #qemu (stsquad) > and #linaro-virtualization (ajb-linaro). > > Many thanks to the SUSE guys for getting the aarch64 train rolling. I > hope your happy with the final result ;-) > > Cheers, > > -- > Alex Bennée > QEMU/KVM Hacker for Linaro > > [1] git://git.qemu.org/qemu.git master > [2] > http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/openSUSE-13.1-ARM-JeOS.aarch64-rootfs.aarch64-1.12.1-Build32.1.tbz > [3] > http://people.debian.org/~wookey/bootstrap/rootfs/debian-unstable-arm64.tar.gz > [4] http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64.tar.gz > [5] https://github.com/stsquad/qemu/tree/ajb-a64-working > [6] https://github.com/susematz/qemu/tree/aarch64-1.6 > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
