I've tested the modified libc from http://people.ubuntu.com/~lool/glibc-
neon/, on kernels both with and without the CONFIG_NEON enabled.
The libc hwcap setup for NEON appears to work fine.
I put some dummy libraries in /lib and /lib/neon and wrote a simple test
program:
* using a kernel with CONFIG_NEON disabled, the library from /lib is used
* using a kernel with CONFIG_NEON enabled, the library from /lib/neon is used
(as expected).
Regarding the comment above that NEON should imply VFP, I should clarify this a
bit:
* The presence of NEON support on hardware does not necessarily mean that VFP
is there (although in practice we expect that it almost always will be)
* If VFP and NEON are both present, this does imply some extra NEON
floating-point functionality, which is not available if NEON is present but VFP
is absent.
So if the kernel reports HWCAP_NEON, ld.so should not automatically
assume that HWCAP_VFP is present (this matches the current ld.so
behaviour, so it's OK).
However, code which uses NEON floating-point functionality (probably most real
NEON code) can only be guaranteed to run reliably if HWCAP_NEON and HWCAP_VFP
are both reported by the kernel. glibc support this for combinations of hwcaps
as /lib/vfp/neon, /lib/neon/vfp (for example), which should achieve the desired
result.
Here's the output of ldconfig -p (where I've put copies of libc.so.6 in
/lib/neon /lib/neon/vfp and /lib/vfp/neon (there's already one in /lib/vfp,
from libc6-vfp):
libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) =>
/lib/neon/vfp/libc.so.6
libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) =>
/lib/vfp/neon/libc.so.6
libc.so.6 (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) =>
/lib/neon/libc.so.6
libc.so.6 (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) =>
/lib/vfp/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.6.16) => /lib/libc.so.6
(I think that neon/vfp and vfp/neon are interchangeable, but there may
be additional subtleties. When actually running an executable, I get
/lib/neon/vfp/libc.so.6 linked in, but I don't currently know whether
there is a real rule at work or it is just by coincidence that this
library is chosen instead of /lib/vfp/neon/libc.so.6. Probably we should
choose just one of these directory combinations and stick to it:
I vote for neon/vfp (since architecturally the extra functionality is
really an extension to NEON rather than an extension to VFP).
In summary, it looks like everything now works as needed to support
libraries with these different hwcap combinations.
--
NEON and THUMBEE hwcaps
https://bugs.launchpad.net/bugs/343602
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
