NEON and THUMBEE hwcaps

Bug #343602 reported by Loïc Minier on 2009-03-16
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Loïc Minier
Loïc Minier
linux (Ubuntu)
Tim Gardner
Tim Gardner

Bug Description


It's currently relatively hard to detect NEON properly in userland, and would be much easier to rely on hwcaps rather than patch NEON detection code in various places.

The new NEON hwcaps bit was added after THUMBEE, so I think it makes sense to also cherrypick the THUMBEE hwcap bit.

Both patches are aimed at mainline for 2.6.29.


Loïc Minier (lool) wrote :
Loïc Minier (lool) wrote :


NB: We already have THUMBEE support, but we were missing the "thumbee" in hwcap_str[].

Changed in linux:
importance: Undecided → High
milestone: none → ubuntu-9.04-beta
Loïc Minier (lool) wrote :

Sub-ing release for FFE.

Loïc Minier (lool) wrote :

Will require a trivial one line change to gblic's "IMPORTANT_HWCAPS".

Changed in glibc:
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.28-10.33

linux (2.6.28-10.33) jaunty; urgency=low

  [ Scott James Remnant ]

  * SAUCE: nbd: Change default partitions per device to 15
    - LP: #342563

  [ Tejun Heo ]

  * SAUCE: libata: make sure port is thawed when skipping resets
    - LP: #269652

  [ Tim Gardner ]

  * Revert "SAUCE: Auto-load esp module when device opened."
    This driver performs unsafe ISA probes (according to Alan Cox).
    This facilitates gadget slave endpoints in virtual environments.
  * Build ehci, uhci, and ohci into the i386/amd64 kernels
    - LP: #296710

  [ Upstream Kernel Changes ]

  * Add "thumbee" to the hwcap_str array
    - LP: #343602
  * Add HWCAP_NEON to the ARM hwcap.h file
    - LP: #343602
  * x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
    - LP: #292619

 -- Tim Gardner <email address hidden> Mon, 16 Mar 2009 08:19:53 -0600

Changed in linux:
status: Fix Committed → Fix Released
Steve Langasek (vorlon) wrote :

FFe granted.

Changed in glibc:
status: New → Confirmed
Loïc Minier (lool) wrote :

Need to patch glibc for NEON hwcaps:
PROCINFO_CLASS const char _dl_arm_cap_flags[10][10]
= {
    "swp", "half", "thumb", "26bit", "fast-mult", "fpa", "vfp", "edsp",
    "java", "iwmmxt",

in ports/sysdeps/unix/sysv/linux/arm/dl-procinfo.c
(add "thumbee" and "neon" I think, checking with people who run the new kernel)


/* The following must match the kernel's <asm/procinfo.h>. */
#define HWCAP_ARM_SWP 1
#define HWCAP_ARM_HALF 2
#define HWCAP_ARM_26BIT 8
#define HWCAP_ARM_FPA 32
#define HWCAP_ARM_VFP 64
#define HWCAP_ARM_EDSP 128
#define HWCAP_ARM_JAVA 256
#define HWCAP_ARM_IWMMXT 512

in ports/sysdeps/unix/sysv/linux/arm/sysdep.h
(needs new defines)

Then patch HWCAP_IMPORTANT as in

Matt Zimmerman (mdz) on 2009-03-25
Changed in glibc (Ubuntu Jaunty):
status: Confirmed → Triaged
Loïc Minier (lool) wrote :

Trick to see hwcaps from /proc/self/auxv as seen by
% LD_SHOW_AUXV="" cat </dev/null
AT_HWCAP: swp half thumb fast-mult vfp edsp
AT_PHDR: 0x8034
AT_BASE: 0x40000000
AT_ENTRY: 0x8ba8
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_EXECFN: /bin/cat

Trick to force hwcaps on a platform:
% sudo LD_HWCAP_MASK=0x0 ldconfig
now wont find any additional hwcap selected libs in the ldconfig cache:
% ldconfig -p | grep vfp
% ldd /bin/ls | grep vfp

Loïc Minier (lool) wrote :

To force e.g. usage of thumb hwcaps:
% sudo mkdir /lib/thumb
% sudo cp /lib/libm* /lib/thumb
% sudo LD_HWCAP_MASK=0x4
% ldconfig -p | grep thumb (libc6, hwcap: 0x0000000000000004, OS ABI: Linux 2.6.16) => /lib/thumb/ (libc6, hwcap: 0x0000000000000004, OS ABI: Linux 2.6.16) => /lib/thumb/

Loïc Minier (lool) wrote :

Note for self: there's theoritically support for a NT_GNU_HWCAP section (.note.gnu.hwcaps ELF section), but I don't think ld/as have any support for setting it in the binaries they output; in fact looking at SSE2 hwcap-selected binaries on my i386 system and at hwcap-selected binaries on my armel system, I couldn't find any such section in the ELF files. Despite this absence, "hwcap:" flags are computed by glibc on the basis of the pathname alone (e.g. /lib/vfp/ => vfp hwcap).

That's why there's no need to patch the ELF parser to pickup NEON binaries for the above changes.

Loïc Minier (lool) wrote :

(While with Sun ld, there is a .SUNW_cap section created by as.)

Loïc Minier (lool) on 2009-03-30
Changed in glibc:
assignee: nobody → lool
status: Triaged → In Progress
Loïc Minier (lool) wrote :

The proposed changes "worked" on my babbage board in that the resulting libc6 and libc6-vfp packages would still work as before, I could run and reboot the system just fine.

"LD_HWCAP_MASK=0x1040 ldconfig" passes (NEON + VFP), but doesn't change anything as obviously I don't have NEON libs.

I created /lib/neon and copied /lib/vfp/* to it and ran the above ldconfig; then I got:
% ldconfig -p | grep (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) => /lib/neon/ (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) => /lib/vfp/ (libc6, OS ABI: Linux 2.6.16) => /lib/ (libc6, OS ABI: Linux 2.6.16) => /usr/lib/

vim uses libm; I don't know how the selection is performed:
% ldd /usr/bin/vim | grep libm => /lib/vfp/ (0x402e6000)

ideally, neon would imply vfp and turn on this hwcap; I don't know how to achieve this with the current hwcap system. The best is probably to let neon version conflict with vfp versions, but it's suboptimal.

Loïc Minier (lool) wrote :

Dave, could you test this glibc against a NEON enabled kernel and hardware?


Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glibc - 2.9-4ubuntu5

glibc (2.9-4ubuntu5) jaunty; urgency=low

  * This upload allows NEON hwcap usage; FFE LP: #343602.
  * New patch, arm/local-hwcap-updates, add support for some recent ARM hwcaps
  * Update patch arm/local-no-hwcap to also flag HWCAP_ARM_NEON as an
    important hwcap; this adds /lib/neon, /usr/lib/neon etc. to the ldconfig
    and search pathes.

 -- Loic Minier <email address hidden> Tue, 31 Mar 2009 20:28:41 +0200

Changed in glibc:
status: In Progress → Fix Released
Dave Martin (dave-martin-arm) wrote :

I've tested the modified libc from, 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, should not automatically assume that HWCAP_VFP is present (this matches the current 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 in /lib/neon /lib/neon/vfp and /lib/vfp/neon (there's already one in /lib/vfp, from libc6-vfp): (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/neon/vfp/ (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/vfp/neon/ (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) => /lib/neon/ (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) => /lib/vfp/ (libc6, OS ABI: Linux 2.6.16) => /lib/

(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/ 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/ 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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers