[ Basically as found at
http://summit.linaro.org/lcq2-12/meeting/20696/linaro-general-q112-cross-di…
but etherpad data has a lovely habit of going away over time... ]
Current Status
==============
Overall, everything works!! ;-) \o/
Fedora
======
Fedora 17 has been released for primary platforms, but not for
ARM yet. Still some remaining work.
* OMAP4 "doesn't work" (crashes), likely due to reliance on pure
upstream OMAP support rather than TI branches. Other distros have
used TI patches.
* Might be more similar issues around other SoCs that lack support in
upstream kernel.
* omapdrm support will wait until F18 (likely).
* Still need to apply the arm hard-float linker path patches,
including the hacky patch for supporting old and new SONAME
* Still scrubbing code base for use of GCC locking intrinsics (or,
rather where packages have rolled their own). Sharing patches
considered good here.
* "We suck" - Jon Masters
* Normal installer not working for ARM, still using dd mechanism to
flash images to cards.
* Fedora are doing two ARM distros: v7 hardfloat (armv7hl) and v5
softfloat (armv5tel). v5 will be supported for another couple of
years, mainly for RaspberryPi users.
Debian
======
* Architecture qualification underway for next release
(Wheezy/version 7).
* armhf (v7 hardfloat) is fully expected to be accepted as an
architecture for the next release, but not *officially* labelled as
such yet.
* armel is still targetting ARMv4t; will continue to stay supported
until absolute confirmation of no more devices in developer hands.
* need banchmarks to check how much speed is lost with staying to
armv4 and/or reasons from toolchain people why v4t is no longer
supported/doesn't work. Time to open discussion about this again
after the Wheezy release.
* There's an *unofficial* port being made for for RaspberryPi
(raspbian.org) ARMv6 hardfloat enabled for this (forward compatible
with armhf). To support this better in future, would need
additional support in HWCAPS to indicate which instructions are
used in this binary/can be used on this hardware. Could use ELF
headers for similar info for binaries. And corresponding info in
package control file so dpkg can do something sensible (i.e. stop
you installing v7 binaries on v6/v5 hardware.
* Starting early ground work for ARMv8 port.
* No omapdrm support in Debian due to "insane" use of 3.2 kernel for
Wheezy
Ubuntu
======
* Ubuntu 12.04 LTS released (3.2 kernel). Main ARM support is armhf
(v7 hardfloat).
* armel port used to be v7 soft-float, but is now slowly being
downgraded from v7 to v5t. May be deprecated altogether in the
future.
* Quantal (12.10) will likely use Linux 3.5 kernel
* LLVM built code not correct for armhf; under investigation.
* janimo officially volunteered (by infinity) to resolve issues
around Mono.
* Starting early ground work for ARMv8 port.
General / actions
=================
As all the distros are going to be working on bootstrapping ARMv8,
plan to keep using the cross-distro list for discussion of
issues. Linaro will host a bug tracker to help people share work
better.
[ACTION] SteveMcIntyre to get BTS going
Steve's major Ruby issue on ARM (reported widely, see
http://bugs.debian.org/652674 for details) is resolved. Now we can
rely on getcontext/setcontext support in glibc, rather than on Ruby's
(broken) internal implementation from Ruby v1.9+. Re-enable the test
suites now!
[ACTION] Enumerate disabled testsuites across all distros and get them
re-enabled
More regular cross-distro meetings (monthly conf call) considered
useful.
[ACTION] SteveMcIntyre to chase down DaveRusling about reviving
cross-distro meetings.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
[ Basically as found at
http://summit.linaro.org/lcq2-12/meeting/20695/linaro-general-q112-armhf-st…
but etherpad data has a lovely habit of going away over time... ]
Current status
==============
Just about done in the distros!
* Released in Ubuntu 12.04
* About to be accepted as a release architecture in Debian
* Fedora 17
* openSUSE (12.2?)
* ChromeOS switched to hard-float (recently)
We finally got agreement on the runtime linker path for arm
hard-float. All the distros have incorporated the changes for that now
*except* Fedora; they're planning to do it Real Soon Now.
Benchmarks
==========
The early comparisons not clear (differing hw, distro, compilers),
difficult to get directly comparable numbers out.
The latest set from Konstantinos are almost complete - see
https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks201205
for a comparison of Ubuntu 12.04 armhf/armel on a Panda board.
Somebody needs to finish off the GUI test results. Overall, numbers as
expected. Some graphics-heavy and FP-heavy code wins (povray! some
media encoding), most integer code comparisons are neutral.
Remaining work
==============
Work is proceeding on ELF markers/segment definition for ABI. Time to
actually implement the PT_ARM_ARCHEXT segment in binutils and
(e)glibc. SteveMcIntyre working on this.
We need to clearly document what the hard-float ABI is. Plan to
incorporate into or copy the existing soft-float ABI doc at Mentor nee
Code Sourcery.
Java is still a mess:
* http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html
ARMv7 Linux - Headless - Server Compiler
* EABI, VFP, SoftFP ABI, Little Endian*
* possibly would work with ubuntu/debian multiarch
Mono is currently not hardfp and needs work to fix it up. Jani
(janimo) might be a good candidate to fix mono, if we can get some of
his time
libffi gained variadic support last year; wasn't used much so far
ctypes would need patching to use new variadic support in libffi but
ctypes isn't maintained upstream anymore; probably not worth it. Other
places where libffi users may be broken.
Gnat:
* Current port works but not great
* Needs resources to do the real port
Ruby is still exhibiting some crashes in testsuite on Debian, Ubuntu
and Fedora, considered likely to be a glibc locking bug.
[ACTION] UlrichWeigand and SteveMcIntyre to setup a hacking session
this week to try to look into this. RESULT: problem solved -
see http://bugs.debian.org/652674 for more details.
Raspberry Pi
============
Brief discussion. It's known that the Pi can support hard-float if
recompiled for ARMv6 in ARM mode (e.g. unofficial Debian rebuild at
http://www.raspbian.org/). General consensus from the distros: not
interested in doing such ports officially, but we love the community
doing so.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Change the dynamic linker path for ARM hard float executables.
Matches the path discussed and agreed on last week[1]. Carlos will
follow up with the matching patch to GLIBC[2]. I'm happy to if he's
busy.
OK for trunk?
-- Michael
[1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html
[2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html
2012-04-23 Michael Hope <michael.hope(a)linaro.org>
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..3ddf812 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run "classic"
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+ "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+ %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
FYI
-------- Original Message --------
Subject: Fedora 17 ARM Beta Release
Date: Thu, 24 May 2012 01:49:46 +0000
From: Paul Whalen <Paul.Whalen(a)senecacollege.ca>
Reply-To: users(a)lists.fedoraproject.org
To: announce(a)lists.fedoraproject.org <announce(a)lists.fedoraproject.org>
The Fedora ARM team is pleased to announce that the Fedora 17 Beta for
ARM is now available
for download from:
http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/17-Beta/Imag…
Please visit the announcement page for additional information and links
to specific hardware images
as well as QEMU for those who lack ARM hardware.
http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta
We invite you to take part in making Fedora 17 for ARM a solid release
by downloading, testing, and
providing your valuable feedback. Please join us on the IRC in
#fedora-arm on Freenode or send
feedback and comments to the ARM mailing list.
On behalf of the Fedora ARM team,
Paul
Hi,
Linaro connect Q2, approaching the schedule is getting ready. Here is
a selection of sessions most close to cross-distro people, but check
the schedule[1] for other sessions as well. I will link to remote
participation instructions once they are online.
Monday 28th May:
10:00 - 10:45 HKT (02:00-02:45 GMT) ARMHF status discussion
Meetup for folks interested in the hard-float ABI work, discussing
status to date and what's still remaining.
Tuesday 29th May:
08:30 - 09:00 HKT (00:30 - 01:00 GMT) ARM update Plenary
An overview of ARM’s current developments with emphasis on ecosystem
activity relative to Linaro and the open source community, both for
ARMv7 and plans for the emerging ARMv8 standard
Thursday 31st May:
09:00 - 09:55 HKT (01:00 - 01:55 GMT): Enterprise Bootloaders: UEFI,
ACPI, Device Tree Oh My!
Discuss bootloader requirements for enterprise grade Linux on ARM CPUs.
10:00 - 10:45 HKT (02:00 - 02:45 GMT) Cross-distro standardisation /
discussion session
ARM progress in various distros (including the new HF ABI) and
build/port issues - sharing ideas and problems that people may have
related to ARM porting
Riku
[1] http://connect.linaro.org/events/event/linaro-connect-q2-12/#schedule
Hi folks,
We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is
/lib/arm-linux-gnueabihf/ld-linux.so.3
but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.
This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.
I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi,
I would like to propose a change in the rpm provides/requires handling of
libs and binaries.
Right now, we use on arm the architecture to distinguish between hard and
soft fp abi.
This results to the fact that armv7l is complete incompatible to armv7hl
due to the rpm architecture compatibility list (is this true everywhere?)
This is IMHO technical wrong. For example an rpm with a static build soft-fp
binary should be installable on a hard-fp system. The kernel and the
hardware does support it and it would just run.
But furthermore this will make it also impossible later to have mixed systems.
What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64
world did go. Declare i686 backward compatible from x86_64, but to
extent the provides and requires with an extension. So a hf binary will
still require a hf lib.
A patch for rpm which should do this is attached, but I have not tested
it, I have to admit. The reason is that want to discuss it here first,
because this has a big impact: It would suddenly make the old armv7hl rpms
not compatible anymore with the new ones.
So, I would like to here if you share my POV here in general. And secondly,
if you see a chance at all to do this switch.
I promise to take care to push such a patch to rpm upstream, if you want it.
thanks
adrian
PS: I have not evaluated how the NEON VFP world fits in here.
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
Hi folks,
As promised, here's minutes from the call we had this
afternoon. Spoiler: the result we've agreed is
/lib/ld-linux-armhf.so.3
And here's a transcription of the minutes from
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
========================================
Meeting: 13th April 2012, 15:00 UTC
Agenda
------
* Debian/Ubuntu have so far built using /lib/arm-linux-gnueabihf/ld-linux.so.3
* Some other distros (Fedora, OpenSUSE) are still using /lib/ld-linux.so.3 option which matches the older soft-float ABI
* Some people are proposing /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib)
* Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to x86_64, libs still in /lib, from Michael Hope)
* What should we do as a community?
Present
-------
Name Affiliations
Steve McIntyre ARM, Debian, Linaro
Wookey ARM, Debian, Linaro
Richard Earnshaw ARM, gcc
Jeff Law Fedora, Red Hat, gcc, glibc
Jon Masters Fedora, Red Hat
Andrew Haley Fedora, Red Hat, gcc
Andreas Jaeger SUSE, openSUSE, glibc
Carlos O'Donnell Mentor, gcc
Steve Langasek Canonical, Ubuntu, Debian
Dann Frazier Canonical, Ubuntu, Debian
Adam Conrad Canonical, Ubuntu, Debian
Matthias Klose Canonical, Ubuntu, Debian
Mike Frysinger Gentoo
Dennis Gilmore Fedora, Red Hat
Discussion
----------
We started with a couple of questions up front to establish the
grounds for discussion:
* We believed that decision makers were present for all the important
parties, i.e. all the arm hard-float distros, plus toolchain
developers. This meant that a decision taken at the meeting could
be implemented without needing further arguments/negotiations.
* All the people present understood the importance of cross-distro
binary compatibility, and they all wanted it. This led to agreement
that we needed to agree on a standard path for the runtime linker
for ARM hard-float Linux binaries.
Debian and Ubuntu had so far been using the "multi-arch" path of
/lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus
far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others
had proposed alternative paths such as /libhf/ld-linux.so.3 or
/libhfp/ld-linux.so.3 (multilib) or
/lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these
were found to be universally acceptable.
Two parties were likely to be soon affected by an agreement here:
1. Ubuntu 12.04 (releasing with armhf in ~2 weeks)
Adam/Steve L agreed that all efforts would be put in to switch the
compilers in Ubuntu to a new path before release. Default things like
gcc would be correct, but less common tools might still be targetting
the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They
could be fixed in the longer term and would not stop progress here.
2. Mentor (Codebench due for release in ~1 week)
Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3
for hard-float binaries for some time and it was too late to change
that for this upcoming release. Next release due in October. Suggested
and accepted that this should be mentioned in release notes: if people
want to use Codebench on some systems (Debian/Ubuntu and derivatives),
they'll need to tweak their system setup. He may be able to do the
linker change and rebuild in a point release in a few weeks.
It was briefly suggested that the soft-float linker should be renamed
away from /lib/ld-linux.so.3 as well at this time, but that idea was
quickly shot down.
Proposal #1: /lib/ld-armhf.so.3 (not generally liked)
Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered
an acceptable compromise by all)
No need to go any further.
Conclusion
----------
All the people in the meeting agreed: the new runtime linker path for
ARM hard-float Linux binaries was to be
/lib/ld-linux-armhf.so.3
ACTION: People at the meeting to present this decision to their
companies / communities and get the appropriate changes made.
Further discussion
------------------
General unhappiness with the mess that led to this meeting. Future
planning needs to be better between the various groups for the next
time we have a new CPU/ABI/whatever.
ACTION: Jon Masters to talk to the Linux Foundation about setting up a
forum for such discussions.
In the meantime, strong consensus to use the
cross-distro(a)lists.linaro.org mailing list for any more conversations
now we have people in contact.
ACTION: Steve McIntyre to write up the minutes and circulate. Include
an updated linker path patch for gcc to match the decision
made here.
More discussion about triplets and naming, but nothing came of it in
the end. Distro folks have already decided what they're using and have
patched various software to build appropriately. Richard wants to move
gcc's config.guess to use arm-linux-gnueabihf; no strong objections to
that.
Linker path patch for gcc
-------------------------
Adapted from earlier work by Dann Frazier <dann.frazier(a)canonical.com>
and Michael Hope <michael.hope(a)linaro.org>
2012-04-13 Steve McIntyre <steve.mcintyre(a)linaro.org>
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8c9d2e7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run "classic"
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+ "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+ %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
Post-meeting on IRC
-------------------
Suggested that Richard should push the change into gcc trunk
ASAP. Steve McIntyre agreed to work on that with Richard.
Also suggested that we want to get a patch into glibc too to change
the installation path for ARM hard-float. Andrew agreed to push glibc
upstream for that.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hey folks,
The next Connect event is in Hong Kong at the end of May. I'm going to
propose another cross-distro discussion there as normally
happens. There's still time for people to register and turn up in
person if you'd like to come along and can get travel organised,
otherwise I'll post the details here so that people can connect
remotely too.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
2012-03-29 dann frazier <dann.frazier(a)canonical.com>
* config/arm/linux-elf.h: Use alternate linker path
for hardfloat ABI
Index: gcc/config/arm/linux-elf.h
===================================================================
--- gcc/config/arm/linux-elf.h (revision 185708)
+++ gcc/config/arm/linux-elf.h (working copy)
@@ -59,14 +59,21 @@
#define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
+#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
#define LINUX_TARGET_LINK_SPEC "%{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
%{symbolic:-Bsymbolic} \
%{rdynamic:-export-dynamic} \
- -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
+ %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
+ %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
+ %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+ %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+ %{!mfloat-abi: \
+ %{!msoft-float: \
+ %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
-X \
%{mbig-endian:-EB} %{mlittle-endian:-EL}" \
SUBTARGET_EXTRA_LINK_SPEC
