== This week ==
- US Holiday on Monday, January 17th - Backported 202407 - Fix parameter to vrsqte_f64 - Backported 202259 (on read/write branch) - AARCH64, fix return types for vaddvq_s64, vaaddvq_u64
- Backported 202321 - Fix vdup<bhsd>_lane<q>_* instrinsics' lane parameter - Backported 202322 - Fox register constraints for lane intrinsics - Installed Qemu64 simulator and attempted to test aarch64 backports. - Shared library issue is preventing qemu64 from executing; Rob Savoy is investigating
== Next week ==
- Test pending git review backports with Qemu64 if issues resolved - Test backports completed this week on Qemu64
- New backports
== Future ==
Michael Collison michael.collison@linaro.org writes:
== This week ==
<snip>
- Installed Qemu64 simulator and attempted to test aarch64 backports.
- Shared library issue is preventing qemu64 from executing; Rob Savoy
is investigating
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!
Debian is carrying a patch that forces the kernel version to be reported to libc as 3.8.
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 ?
- rob -
+++ 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).
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.000000000 +0000 +++ qemu-1.7.50+dfsg/linux-user/main.c 2014-02-18 16:23:10.340055485 +0000 @@ -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
On 02/23/2014 01:43 PM, Wookey wrote:
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
Ah, thanks for the patch, it did the trick. Now aarch64-linux builds via Jenkins are using it for execution tests, and it appears to be working fine. I patched qemu-aarch64 on all the TCWG build farm machines while I was at it.
- rob -
-----Original Message----- From: linaro-toolchain-bounces@lists.linaro.org [mailto:linaro- toolchain-bounces@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.000000000 +0000 +++ qemu-1.7.50+dfsg/linux-user/main.c 2014-02-18 16:23:10.340055485 +0000 @@ -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
+++ Ramana Radhakrishnan [2014-02-24 09:08 +0000]:
From: linaro-toolchain-bounces@lists.linaro.org [mailto:linaro-
toolchain-bounces@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
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 -
+++ 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
On 24 February 2014 14:54, Rob Savoye rob.savoye@linaro.org 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
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 -
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
On 24 February 2014 15:28, Rob Savoye rob.savoye@linaro.org 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
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 -
On 24 February 2014 16:06, Rob Savoye rob.savoye@linaro.org 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
On 24 February 2014 17:10, Peter Maydell peter.maydell@linaro.org wrote:
On 24 February 2014 14:54, Rob Savoye rob.savoye@linaro.org 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.
+++ Alex Bennée [2014-02-23 10:09 +0000]:
Michael Collison michael.collison@linaro.org writes:
== This week ==
<snip> > - Installed Qemu64 simulator and attempted to test aarch64 backports. > - Shared library issue is preventing qemu64 from executing; Rob Savoy > is investigating
Is this a problem with the emulated shared libraries not loading (qemu itself should be static)?
There seems to be one. Once I got past the uname version issue mentioned below I found that I could run qemu-aarch64-static 'bare' ( so long as links to /lib/aarch64-linux-gnu and /lib/ld-linux-aarch64.so.1 exist in the rootfs). But I haven't yet succeeded in having it run in a chroot under binfmt misc. The shared libs in the chroot (for the to-be-emulated binary, such as /bin/echo or /bin/bash) are loaded but the execve of that binary fails.
I haven't quite yet got to the bottom of this (mostly because something else came up). If anyone else if poking and wants to compare notes that would be good.
Wookey
linaro-toolchain@lists.linaro.org
-
Alex Bennée -
Gregory H. Nietsky -
Michael Collison -
Peter Maydell -
Ramana Radhakrishnan -
Riku Voipio -
Rob Savoye -
Wookey