Re: problem with sigaltstack on aarch64
On 24 February 2014 03:15, Michael Hudson-Doyle wrote: > Michael Hudson-Doyle writes: > >> Michael Hudson-Doyle writes: >> >>> Hi all, >>> >>> Apologies if this is the wrong list, and for the somewhat vague >>> description of my problem. >>> >>> I've been working on porting Go (via gccgo) to aarch64 and things have >>> mostly been going well. However, under some circumstances, I'm seeing >>> crashes. What's happening is that when a signal -- SIGCHLD in this case >>> -- is being handled, instead of being executed on the stack passed to >>> sigaltstack, the signal is being handled on some *other* thread's stack, >>> which unsurprisingly ends badly when a signal context object is smashed >>> over whatever the original thread had put there. > > I finally chased this down to (what at least I think is) a glibc bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=16629 Thanks for another great debugging job! ;-) I'll take a look at this as soon as I'm "back in the office" unless someone gets there first. -- Will Newton Toolchain Working Group, Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 32bit binaries on 64-bit linux (fixed)
+++ Wookey [2014-01-29 16:36 +]: > Someone asked if this worked, and I thought 'that's trivial to test with > multiarch' so I did. > On Saucy (where there is no multiarch version skew issue between binary > versions of packages) the > dpkg --add-architecutre armhf > apt-get update > apt-get install links:armhf > part works very nicely. Everything installs as required. > > However binaries don't run - they just get killed. > > Turns out that our arm64 kernel config has: > vm.mmap_min_addr=65536 > but armhf binaries tend to get mmapped at 0x8000 (32K). This has been fixed in the default kernel configs now. > part2: Once this is fixed > some binaries work (hello, bzip2) but fancier things still don't (links, > wget). They segfault after loading libs. I'm still investigating that, > but it looks like we have at least two issues.. So after rather a lot of faffing round related issues I got to the bottom of this problem which turned out to be 'kernel too old'. The Linaro Foundation 3.8 kernels I was using doesn't work in this regard. Changing to last month's release (and munging the kernel command line with the very cool kcmt utility works fine). So, I've now uploaded A saucy armhf/arm64 configured multiarch image and tarball to: http://people.debian.org/~wookey/bootstrap/rootfs/ 2G disk image: (as 92MB file) http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64-multiarch.img.xz Corresponding kernel: http://people.debian.org/~wookey/bootstrap/rootfs/linux-system-foundation.axf tarball of same rootfs: http://people.debian.org/~wookey/bootstrap/rootfs/saucy-multiarch.tar.gz All linked on https://wiki.debian.org/Arm64Port#Pre-built_Rootfses Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with sigaltstack on aarch64
Will Newton writes: > On 24 February 2014 03:15, Michael Hudson-Doyle > wrote: >> Michael Hudson-Doyle writes: >> >>> Michael Hudson-Doyle writes: >>> Hi all, Apologies if this is the wrong list, and for the somewhat vague description of my problem. I've been working on porting Go (via gccgo) to aarch64 and things have mostly been going well. However, under some circumstances, I'm seeing crashes. What's happening is that when a signal -- SIGCHLD in this case -- is being handled, instead of being executed on the stack passed to sigaltstack, the signal is being handled on some *other* thread's stack, which unsurprisingly ends badly when a signal context object is smashed over whatever the original thread had put there. >> >> I finally chased this down to (what at least I think is) a glibc bug: >> https://sourceware.org/bugzilla/show_bug.cgi?id=16629 > > Thanks for another great debugging job! ;-) Heh, I find it hard to give up... I should probably get help about that! > I'll take a look at this as soon as I'm "back in the office" unless > someone gets there first. Cool. I'm certainly happy to test any fixes, and could even try to work on one myself with a few hints... Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
qemu crash
I sent the below to the list before I was a subscriber and I don't think it made it through. - I don't know if I'm having a problem with QEMU or the linaro system image I'm using or something else, so I'm posting it here. Let me know if there's a more appropriate place. I'm experiencing the following crash: $ qemu-system-arm -machine beagle -nographic -sd linaro-saucy-nano-20140126.img qemu: fatal: Trying to execute code outside RAM or ROM at 0x402f0400 R00=40014044 R01=402f0400 R02= R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13=4020fcb0 R14= R15=402f0400 PSR=41df -Z-- A sys32 s00= s01= d00= s02= s03= d01= s04= s05= d02= s06= s07= d03= s08= s09= d04= s10= s11= d05= s12= s13= d06= s14= s15= d07= s16= s17= d08= s18= s19= d09= s20= s21= d10= s22= s23= d11= s24= s25= d12= s26= s27= d13= s28= s29= d14= s30= s31= d15= s32= s33= d16= s34= s35= d17= s36= s37= d18= s38= s39= d19= s40= s41= d20= s42= s43= d21= s44= s45= d22= s46= s47= d23= s48= s49= d24= s50= s51= d25= s52= s53= d26= s54= s55= d27= s56= s57= d28= s58= s59= d29= s60= s61= d30= s62= s63= d31= FPSCR: Aborted (core dumped) Here's how I created the image: linaro-media-create --dev beagle \ --hwpack hwpack_linaro-beaglebone_20140203-602_armhf_supported.tar.gz \ --binary linaro-saucy-nano-20140126-627.tar.gz \ --image-file linaro-saucy-nano-20140126.img I get the same error on the following OS/qemu combos: Ubuntu Trusty $ qemu-system-arm --version QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3ubuntu1), Copyright (c) 2003-2008 Fabrice Bellard Ubuntu Saucy $ qemu --version QEMU emulator version 1.5.0 (Debian 1.5.0+dfsg-3ubuntu5.2), Copyright (c) 2003-2008 Fabrice Bellard MacOS 10.8.5 QEMU emulator version 1.7.0 (qemu-linaro 2014.01), Copyright (c) 2003-2008 Fabrice Bellard I get a similar error at a different address with this highbank image: http://releases.linaro.org/14.01/ubuntu/highbank/highbank-saucy_server_20140126-596.img.gz $ qemu-system-arm -machine highbank -nographic -sd highbank-saucy_server_20140126-596.img qemu: fatal: Trying to execute code outside RAM or ROM at 0x0800 I am able to boot this oneiric image: http://releases.linaro.org/images/12.03/oneiric/nano/beagle-nano.img.gz Can somebody supply me with a working qemu beaglebone command line? What does LAVA use? Thanks, Dan___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
