arm August 2007

arm@lists.fedoraproject.org

5 participants
4 discussions

[RFC] new fedora ARM cross toolchain RPMS available
by Lennert Buytenhek 26 Aug '07

26 Aug '07

Hi all, I've made a new set of fedora ARM cross toolchain RPMS available at: http://www.wantstofly.org/~buytenh/cross/ These RPMS are built from vanilla Fedora sources, with only packaging (.spec) changes. The goal is to produce a complete cross toolchain that is as close as possible to a native Fedora toolchain, and usable to cross-build Fedora packages with which are fully binary compatible with natively built packages, with as little source/packaging changes to the package as possible. To try it out, drop cross.repo into /etc/yum.repos.d/, and run # yum install armv5tel-redhat-linux-gnueabi-gcc The cross-compiler package will pull in a set of noarch RPMS containing target libraries, such as glibc. These libraries are installed in the default gcc sysroot location (/usr/$target_triple/sys-root), and the noarch RPMS that contain said libraries are created by repack_cross.pl, provided in the same directory as above. After installation, you will end up with /usr/bin/armv5tel-redhat-linux-gnueabi-gcc, which can be used to build ARM binaries just like you would build i386 binaries. To cross-build an autoconf-using package, specify --host and/or --target on the autoconf command line. For example, to build an ARM binary of bash-3.2 on your i386 machine, you would do: $ ./configure --host=armv5tel-redhat-linux-gnueabi $ make This works fine, and the resulting binary runs fine in an FC6 ARM chroot on real ARM hardware. Please send feedback. :-) thanks, Lennert

1 1

occasional rpm environment corruption
by Lennert Buytenhek 22 Aug '07

22 Aug '07

I've been chasing a 'weird rpm messages on ARM' problem for some time now, below is a brain dump of what I've found so far. Very sporadically, rpm/yum on arm get into a state where they spit out things like: Installed: unix2dos.armv5tel 0:2.2-26.2.2 Complete! rpmdb: Locker still has locks error: db4 error(22) from db->close: Invalid argument or: # yum install libsoup-devel Loading "installonlyn" plugin rpmdb: Locker is not valid rpmdb: Unknown locker ID: ae1 error: db4 error(22) from db->close: Invalid argument error: cannot open Packages index using db3 - Invalid argument (22) error: cannot open Packages database in /var/lib/rpm This doesn't happen very often, but it's annoying enough when it does. When it happens, the rpm database itself is totally intact, but some corruption occurs in the /var/lib/rpm/__db.00x database environment files -- specifically, the lock region (which is usually __db.003.) The regular rpm recovery procedure (rm __db.* and then --rebuilddb) always gets things working again. Note that this is a general issue seen with db4, and is not rpm-specific. After having spent some time looking at the relevant db4 code back in May, at first I thought that it might be some kind of aliasing problem between mmap() and read(), since db4 appeared to be using both mmap() and regular read()/write() to access its data files -- note that most ARMs use virtual caches, which are susceptible to all kinds of aliasing issues. Testing did turn up such an aliasing issue in the kernel: http://marc.info/?l=linux-arm-kernel&m=117995603418036&w=2 However, fixing that issue didn't fix the corruption. As it turns out: 1. db4 exclusively uses read()/write() to access its database files, and exclusively uses mmap() to access its environment (__db.00x) files, mapping only a single copy of each environment file into a single process, so that aliasing issues can not occur. 2. The corruption also happens in qemu ARM system emulation (http://fedoraproject.org/wiki/ARM/HowToQemu) while qemu does not emulate virtual caches at all. Cache aliasing issues should not occur in qemu. Google reports a lot of cases of people seeing similar errors from rpm. However, in pretty much all of these cases, what is happening is that people end up with stale locks because of Ctrl-C'ing processes that interact with the RPM database or similar -- the db4 version that rpm uses doesn't recover such stale locks very well or at all. This doesn't line up with what we are seeing -- we sometimes see these errors from rpm even while populating a new chroot from scratch, for example using pilgrim. There is another report of db4 corruption on arm with symptoms similar to ours, by Andy Green: http://marc.info/?l=linux-arm-kernel&m=118064698109089&w=2 However, this is also not the same issue as we are seeing, for two reasons: - His issue is 100% reproducible, and happens on startup. Ours only hits sporadically, and is very hard to reproduce. (Rolling back the RPM database and repeating the offending command pretty much never manages to reproduce it in our case.) - His issue disappears entirely when adding some printfs to a couple of db4 functions. This suggests that he is seeing some compiler optimisation bug (he uses gcc 4.0.3, we use unmodified Fedora gcc (redhat branch)) I've tried building with -O0, but that makes no difference in our case. After digging a lot deeper into db4, what it appears like is that when this surfaces, db4's internal linked list structures (the ones implemented by db4's shqueue.h, in shared memory) that are used to keep track of outstanding locks and lock objects end up corrupted. Specifically, it seems as if writes to the writable mmap() of /var/lib/rpm/__db.003 never make it to disk (i.e. a dirty page is dropped without a writeout), and later on, a stale version of that page is read back in from disk. One clue is that in one instance, while walking one of those lists, db4 ended up dereferencing an invalid userspace pointer -- which led to this bug report: http://marc.info/?l=linux-arm-kernel&m=118712875312492&w=2 In another specific case, after rpm exited I ended up with the lock region showing a negative number of active lock objects. Some debugging suggested that while the list of lock objects was being walked, a stale version of one of the 'next' pointers in the list was somehow read back in from disk, causing some of the elements on that list to be 'deleted' twice, turning the count of elements on the list negative. As I said, it is very hard to reproduce this issue on demand, and so it is even harder to debug it. To test whether it's an issue of lost writes to shared mmap() areas, I've made my version of rpm mlock() its db4 environment files immediately after mapping them. If I don't see this issue re-surface in the next month or so, I can be reasonably confident that it has something to do with this. If it is what I think it is at this point, it might be an issue on x86 Linux kernels too -- it just might be that x86 machines don't see it happening since they typically have more RAM and thus typically less memory pressure, so that there is less pageout/writeout activity. Shared mmap() is certainly one of the things that has had a lot of bugs found in it in the past (the semi-recent Linux rtorrent corruption issues were basically due to the same type of issue), and might just not be entirely bug-free yet. For now, I'm not entirely sure what else I can do to debug this. The harder I try to reproduce this, the less it occurs. If you run into this issue, please just perform the manual rpm recovery procedure (after sending me a copy of your /var/lib/rpm directory, if possible.) Sorry for the inconvenience.

1 0

ARM EABI gcc-java support..
by Lennert Buytenhek 10 Aug '07

10 Aug '07

gcc-java support for ARM EABI is getting closer.. ----- Forwarded message from aph at gcc dot gnu dot org <gcc-bugzilla(a)gcc.gnu.org> ----- Date: 9 Aug 2007 17:44:23 -0000 X-Bugzilla-Reason: CC Subject: [Bug target/31325] gcj support for ARM EABI In-Reply-To: <bug-31325-12652(a)http.gcc.gnu.org/bugzilla/> Reply-To: gcc-bugzilla(a)gcc.gnu.org To: buytenh(a)wantstofly.org From: "aph at gcc dot gnu dot org" <gcc-bugzilla(a)gcc.gnu.org> ------- Comment #21 from aph at gcc dot gnu dot org 2007-08-09 17:44 ------- I've created abranch for this work at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch It's mostly done, but there are still some bugs. I'll post the patches to the gcc list when they're in a fit state. -- aph at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 19:32:20 |2007-08-09 17:44:23 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ----- End forwarded message -----

2 1

arm-linux-gnueabi toolchain available
by Brendan Conoboy 08 Aug '07

08 Aug '07

A few weeks back there was a big discussion on fedora-devel-list about cross compilers in relation to the Fedora arm project. Somewhere in the thread I promised we (GES @ Red Hat) would put out our cross compilation bits as proof of concept. While we're still making some changes to our cross rpm packages, we can share our current cross compiler beta for those who are interested. We're producing working root filesystems with this compiler, so you should be able to as well. A couple things to note: The tools are portion of the GNUPro toolkit currently in development (aka gnupro-07r1-1) and is not based on the sources from Fedora (It is gcc 4.2.1, for instance). We don't normally build with RPM, so the spec file is a wrapper to our rebuild program (Which handles the chicken/egg problem aka gcc/glibc). Source and binary RPMs are available here: ftp://ftp.ges.redhat.com/private/releng/arm-linux-beta These were built on a 32 bit RHEL3 host. It works just as well on a x86_64 Fedora 7 box, so no worries if you want to rebuild. Unless otherwise directed, tools will install under /opt/redhat/gnupro-07r1-1/H-%{_host}/bin To rebuild you need to define %target like so: rpmbuild -ba --define 'target arm-linux-gnueabi' gnupro.spec All feedback appreciated. -- Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm August 2007