Appologies
Hi All, Apologies for missing the stand-up call today. I've been having technical difficulties at my end. :( I think they're resolved now ... maybe. Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro QEMU 2011.07 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2011.07. Linaro QEMU 2011.07-0 is the latest monthly release of qemu-linaro. Based off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes and enhancements. This month's release is primarily minor improvements: - Fixes a compile failure on ia64 hosts - syscall 369 (prlimit64) implemented in linux-user mode - Fixes an ELF loader bug that caused problems with binaries generated by the Google Go compiler Plus of course new upstream fixes and improvements. Known issues: - The beagle and beaglexm models still do not support USB networking - Very recent Linaro omap3 hwpacks (20110716 and later) do not boot on the beagle model; this is caused by an x-loader bug (LP:813407) The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2011.07 Binary builds of this qemu-linaro release are being prepared and will be available shortly for users of Ubuntu. Packages will be in the linaro-maintainers tools ppa: https://launchpad.net/~linaro-maintainers/+archive/tools/ More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] July 17-21
Hi, - I finally submitted the over-widening patch, but Richard Guenther thought that this optimization should be done for scalars as well, and he is now working on this himself. - Some auto-vectorizer fixes Ira ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Using valgrind with linaro toolchain
Valgrind wants a less stripped ld-2.12.1.so or it won't work. The build process (that Michael Hope put together) just downloads the libc6_2.12.1-0ubuntu6_armel.deb, and the ld-2.12.1.so in there is fully stripped. I thought I'd be able to just get the libc6-dbg_2.12.1-0ubuntu6_armel.deb instead, thinking that was just the pre-stripped version of these libs -- but apparently it's not, because trying to use those libs instead of the stripped ones results in undefined symbols. For example, ld-2.12.1.so defines _rtld_global -- but libc-2.12.1.so is looking for _rtld_global@@GLIBC_PRIVATE, so _rtld_global@@GLIBC_PRIVATE ends up undefined. (Ditto for __tls_get_addr, __libc_enable_secure, _dl_argv, etc.) I'm not sure who actually builds these packages (they're retrieved from: http://ports.ubuntu.com/pool/main/e/eglibc/), but if anyone has any suggestions on how to get past this, I'd be most appreciative. (I've got angry developers trying to track down memory issues, who about to come after me with torches and pitchforks :P ) Thanks, Diane ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Using valgrind with linaro toolchain
On 07/21/2011 08:49 PM, Diane Holt wrote: > Valgrind wants a less stripped ld-2.12.1.so or it won't work. The build > process (that Michael Hope put together) just downloads the > libc6_2.12.1-0ubuntu6_armel.deb, and the ld-2.12.1.so in there is fully > stripped. I thought I'd be able to just get the > libc6-dbg_2.12.1-0ubuntu6_armel.deb instead, thinking that was just the > pre-stripped version of these libs -- but apparently it's not, because > trying to use those libs instead of the stripped ones results in undefined > symbols. the files in /usr/lib/debug are built with objcopy --only-keep-debug, so only include the debug info. the stripped files get a debug link added (objcopy --add-gnu-debuglink). For example, ld-2.12.1.so defines _rtld_global -- but > libc-2.12.1.so is looking for _rtld_global@@GLIBC_PRIVATE, so > _rtld_global@@GLIBC_PRIVATE > ends up undefined. (Ditto for __tls_get_addr, __libc_enable_secure, > _dl_argv, etc.) > > I'm not sure who actually builds these packages (they're retrieved from: > http://ports.ubuntu.com/pool/main/e/eglibc/), but if anyone has any > suggestions on how to get past this, I'd be most appreciative. Did that work in the past? Can valgrind handle detached debug information? If not, then maybe call dh_strip in the eglibc package with -Xld-2.13.so Matthias ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Using valgrind with linaro toolchain
On Thu, Jul 21, 2011 at 12:04 PM, Matthias Klose wrote: > the files in /usr/lib/debug are built with objcopy --only-keep-debug, so > only > include the debug info. the stripped files get a debug link added (objcopy > --add-gnu-debuglink). > Well, that would explain that :( I had assumed they were just the full, unstripped versions of the libs. Would those be available from anywhere? > Did that work in the past? > What worked in the past was having a loader lib that wasn't stripped (we would later do a 'strip --strip-unneeded --strip-debug' on it, which is fine -- it's just when it's completely stripped of all symbols that valgrind can't function). That's when we were using the 4.4.1 from CodeSourcery (none of the libs are stripped). Switching to linaro means I have to build the toolchain myself, and its build just picks up the libs from the libc6_2.12.1-0ubuntu6_armel.deb package, and those libs are fully stripped. Can valgrind handle detached debug information? I doubt it (can't think how that would work... but I'm open to suggestions). > If not, then maybe call dh_strip in the eglibc package with -Xld-2.13.so > I'm not building eglibc -- the linaro build process doesn't include doing that, and I don't have any information on how libc6_2.12.1-0ubuntu6_armel.deb (what the linaro build process uses) was built. Thanks, Diane ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Using valgrind with linaro toolchain
Okay, it looks like this is the source: https://launchpad.net/ubuntu/+source/eglibc/2.12.1-0ubuntu6 So I downloaded it and tried building it. (I got eglibc-ports-2.12 from cross-lfs.org, which was the only one I could find anywhere.) I already have an ARM environment (using the linaro 4.5.4 I built), so I figured I could just build it, without all the cross-compile contortions. It actually looked like it might even work -- but it failed on the compile of sigrestorer.o: ../../eglibc-ports-2.12/sysdeps/unix/sysv/linux/arm/sigrestorer.S: Assembler messages: ../../eglibc-ports-2.12/sysdeps/unix/sysv/linux/arm/sigrestorer.S:30: Error: previous CFI entry not closed (missing .cfi_endproc) ../../eglibc-ports-2.12/sysdeps/unix/sysv/linux/arm/sigrestorer.S:31: Error: open CFI at the end of file; missing .cfi_endproc directive make[2]: *** [/home/diane/src/eglibc/build/signal/sigrestorer.o] Error 1 make[2]: Leaving directory `/home/diane/src/eglibc/eglibc-2.12.1/signal' make[1]: *** [signal/subdir_lib] Error 2 make[1]: Leaving directory `/home/diane/src/eglibc/eglibc-2.12.1' make: *** [all] Error 2 Googling the error turned up this: "I think you are making things much more complicated than necessary. It seems more likely that all that's needed is adding END calls to match the ENTRY ones in sysdeps/unix/sysv/linux/arm/sigrestorer.S. Note that old-ABI has been essentially unmaintained for a long time now; I strongly recommend moving to EABI. sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S has the END calls and the file you reference should not be used at all in an EABI build." I did do what was suggested (added the END calls), which got me past that error -- but I hit another one, compiling getrlimit.o: In file included from ../../eglibc-ports-2.12/sysdeps/unix/sysv/linux/arm/getrlimit.c:1:0: ../sysdeps/unix/sysv/linux/i386/getrlimit.c: In function '__new_getrlimit': ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65:1: error: '__NR_getrlimit' undeclared (first use in this function) ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65:1: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [/home/diane/src/eglibc/build/resource/getrlimit.o] Error 1 make[2]: Leaving directory `/home/diane/src/eglibc/eglibc-2.12.1/resource' make[1]: *** [resource/subdir_lib] Error 2 Why it's compiling a file in an i386 subdir, I have no idea :P So, given what joseph said about sigrestorer.S shouldn't even be in the build, and given this error, I'm worried that either I don't have the right ports file, or I'm just not building this right. Matthias, are you the one who's building this source? If you are, do you have any instructions on how to do it? I really, really need an unstripped ld-2.12.1.so, and it looks like building it myself is the only way I can get one. Thanks, D. On Thu, Jul 21, 2011 at 12:38 PM, Diane Holt wrote: > > On Thu, Jul 21, 2011 at 12:04 PM, Matthias Klose wrote: >> >> the files in /usr/lib/debug are built with objcopy --only-keep-debug, so only >> include the debug info. the stripped files get a debug link added (objcopy >> --add-gnu-debuglink). > > Well, that would explain that :( I had assumed they were just the full, > unstripped versions of the libs. Would those be available from anywhere? > >> >> Did that work in the past? > > What worked in the past was having a loader lib that wasn't stripped (we > would later do a 'strip --strip-unneeded --strip-debug' on it, which is fine > -- it's just when it's completely stripped of all symbols that valgrind can't > function). That's when we were using the 4.4.1 from CodeSourcery (none of the > libs are stripped). Switching to linaro means I have to build the toolchain > myself, and its build just picks up the libs from the > libc6_2.12.1-0ubuntu6_armel.deb package, and those libs are fully stripped. > >> Can valgrind handle detached debug information? > > I doubt it (can't think how that would work... but I'm open to suggestions). > >> >> If not, then maybe call dh_strip in the eglibc package with -Xld-2.13.so > > I'm not building eglibc -- the linaro build process doesn't include doing > that, and I don't have any information on how libc6_2.12.1-0ubuntu6_armel.deb > (what the linaro build process uses) was built. > > Thanks, > Diane > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
