On arm* sys/ucontext.h heavilly polloutes the global
namespace firstly by including sys/user.h (which defines
among other things a type called "struct user" and secondly
by defining symbols and #defines named R? to represent
the processor registers.
That issue in itself is nothing new but fairly recently*
signal.h started including sys/ucontext.h by default
causing programs that (quite reasonable IMO) used those
names for their own symbols to fail to build on arm. This
has been especially noticable recently because debian is
trying to build the new "armhf" port.
After discussions on debian-arm/debian-glibc/linaro-dev
(I do not know which responders came from which list)
I was given the following advice on the "struct user"
issue by Ulrich Weigand.
>Now, glibc also provides a file <sys/ucontext.h> that defines
>layouts of register sets for use with signal handlers as well
>as the makecontext/setcontext/getcontext family of routines.
>
>Usually, those layouts tend to be in fact identical to the
>layouts described in <sys/user.h> / <sys/procfs.h>. Apparently,
>whoever implemented the ARM version of <sys/ucontext.h> was
>trying to avoid some seemingly unnecessary code duplication
>by making <sys/ucontext.h> *include* <sys/procfs.h> and using
>the information from there directly. This is not done on other
>platforms, for precisely the reason that the <sys/procfs.h>
>and <sys/user.h> headers do pollute the name space ...
>
>So I think the right thing to do in the short term would be to
>stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the
>register set information there directly, even if that means some
>duplication of code. (Again, since this is never-changing ABI,
>duplication isn't actually all that bad. Also, all the other
>platforms do it that way too, so why should ARM be different ...)
On the issue of the R? definitions I proposed renaming them
to REG_R?. The use of a REG_ prefix is consistent with
x86, x64 and sparc (I couldn't find any comparable definitions
at all on other architectures I looked at) I asked what the
impact of this change would be on the aforementioned mailing
lists and got the following reply from Konstantinos Margaritis
>at worst the packages that had to be workaround on arm* for this, can
>have the workaround removed.
The attached patch implements these changes.
My tests did not show any new failures in the libc testsuite (though
I did get failures that debian considers "unexpected" regardless
of whether this patch is applied or not)
The patch was accepted upstream by Joseph Myers <joseph(a)codesourcery.com>
http://sourceware.org/git/?p=glibc-ports.git;a=commitdiff;h=c1e30fd8bffd53a…
The patch was also accepted in debian sid by Aurelien Jarno
<aurel32(a)debian.org>
http://packages.qa.debian.org/e/eglibc/news/20111225T171844Z.html
I have been advised by hector oron to send this to the cross-distro list
in-case other distros are interested in applying this fix before it filters
down naturally from upstream.
* I have not investigated exactly when this change occoured
but it was somewhere between the version in ubuntu lucid
and the version in ubuntu maverick.
Hey folks,
Continuing on from the discussions at LC last week, here are my two
patches. They work OK for me in testing on armhf and armel builds
here, so I hope they are helpful for other people.
Background: in bi-arch and multi-arch configuration, soft-float and
hard-float libraries do not play well together at all:
* ldconfig (currently) does not distinguish between the two ABIs when
scanning libraries and putting their details in ld.so.cache, so if
you have libs of both ABIs installed on your system then there is
no guarantee that the right one will be used when needed.
* ld.so (currently) cannot verify at run-time whether a given lib
uses the hard-float or soft-float ABI, which can lead to similar
problems.
I previously had just a patch against ld.so for this, causing it to
fail to load a library when the wrong ABI was detected. However, more
testing has shown that this is not a sufficient solution. ld.so trusts
the contents of the cache, so I've had to add logic into ldconfig
itself and add extra information in the cache to describe the ABI of a
library. There's already similar code in there to recognise 32-bit
libs on a 64-bit system, so I've extended things in what I hope is a
clean way. Unfortunately, there are also paths through ld.so that
*don't* use the cache anyway so we still need the checks in there as
well. If the wrong lib is loaded by mistake, return ENOENT so that a
fallback is attempted.
For now, there's a fair amount of duplication in the code in each
patch. I'd be happier to see it cleaned up and shared better, but my
initial efforts in that direction have been thwarted by the internals
of eglibc - the (very minimal) infrastructure available in ld.so is
very different to that in ldconfig (an entirely normal and boring C
application). If anybody fancies trying that cleanup, please feel
free... :-)
As the list drops attachments, here are links to the two patches:
http://people.linaro.org/~stevemcintyre/armhf/unsubmitted-ldconfig-cache-ab…http://people.linaro.org/~stevemcintyre/armhf/unsubmitted-ldso-abi-check.di…
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi guys,
We are currently slightly stuck in getting GNU Java to work properly on
our ARM (hf) builds. Something breaks in the unrolling of exceptions.
IIUC Fedora already managed to get Java running and I don't want to
waste too much time in duplicated efforts.
We found some patches that looked like they might be related here:
http://djdelorie.fedorapeople.org/armv7-srpms.html (gcc pkg)
but couldn't find the source rpms to the respective info. Are these
related / required? Does anyone have some insight in what exactly you
have been fixing?
Btw, this is what we're seeing:
---
+ gcj -C /home/abuild/rpmbuild/SOURCES/keystore.java -d .
qemu: uncaught target signal 6 (Aborted) - core dumped
gcj: internal compiler error: Aborted (program ecj1)
---
Alex
Just talking to folks in Orlando, and it seems we have another
problem...
ld.so uses ld.so.cache to look for libraries to load. On a bi-arch
system with soft-float and hard-float libs, that could lead to us
using the wrong library. Matthias Klose just showed me a broken gcc
build where armhh was trying to load libraries from
/lib/arm-linux-gnueabi because that's what is listed in the cache.
Two solutions present themselves:
* move ld.so.cache to a m-a path too; it's currently broken both in
having cached data in /etc (!) and in not distingushing properly
between systems
* add in support for distingushing the ABIs (again!) - currently the
32- and 64-bit x86 systems do this
Neither looks like fun... :-(
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
[ Please forward this to anyone else who should get a copy - and ask
them to signup to cross-distro@linaro because that's where we'll talk ]
Folks,
At the 2011 Linux Plumbers Conference in Santa Rosa, we held an ARM
minisummit to discuss a few cross-distribution issues surrounding the
"hard float" ABI for v7, and the ARM device and OS ecosystem in general.
This mail is intended to summarize the key actions from that meeting.
1). We discussed some of the different distributions (Debian, ChromeOS,
Fedora, MeeGo, Mozilla, Ubuntu, etc.). We all agree on a common notion
of what "hard float" means: it's the ARM AAPCS hardware floating point
stuff in section 6, with the -d16 register set of the VFPv3 being used.
Although there is some possibility to standardize v6, we decided we are
interested only in the present and future at this point (and that's v7).
Some use Thumb2, some don't, but interworking allows for that (we in
Fedora accidentally built a few packages with Thumb2 and will be undoing
that without users even noticing). NEON is similarly an optional feature
(supported by hwcaps) and not a required part of the core ABI. So it's
really just the ABI that we all care about, and we all agree on it.
For toolchain folks, this means we all agree on the following:
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
(some of us may target different optimizations, etc. of course but that
is down to an application to decide whether it cares only about Cortex+)
2). We agreed on the importance of cross-distro binary compatibility. It
seems a number of distributions are excited by Debian's multi-arch
approach (as am I), but not all of us will be moving to it any time
soon. In the shorter term, if the runtime linker will have a special
path, we can work around that with symlinks, but it's a kludge. Our
preferred goal (from the meeting) is that everyone use this target:
arm-linux-gnueabihf
(Red Hat toolchains will include the vendor, but it is dropped by
autotools when actually generating the paths and comparisons). I will
advocate for Fedora ARM to switch to this target when possible, and in
the interim will try to ensure we can establish some symlinks for the
ability to run binaries compiled against Debian and Ubuntu on Fedora. I
don't know what our timeline will be for this, but it's not something
that's really landed everywhere yet. We at least agree on paths now!
3). We agree that it is a good idea to do LSB. Adam Conrad (Canonical)
and I agreed to represent community interests in driving this. We do
know that we'll be preferring OpenGL ES 2.0 over OpenGL (same namespace
within the library means one default choice is required). There will be
many other things :) We agree that the main benefit to pursuing LSB is
that it promotes the idea of working together and being compatible. It
may be that we don't have the same level of compliance on ARM, but some
level of conformance to some common standard(s) is a good start! :)
4). We decided that we should have a standing Cross Distro meeting at
Linaro Connect events, beginning with the next one in November. We will
also facilitate a "show and tell" for apps at Connect, and have an
opportunity to demo different distributions. We will add a specific
session at the next Connect to continue this discussion.
Finally, we agreed we should keep the conversation going. I apologize
for being a little tardy in sending this mail, but I want to kickstart
further discussion and get this ball rolling again. I'll ping Adam about
LSB (and thanks again to Jesse for the deep dive on GL). Meanwhile,
David can grab ownership of organizing the Cross Distro meeting at
Connect (I would like to assist). Anyone else got actions?
Jon.
