Thread (76 messages) 76 messages, 8 authors, 2014-07-22
STALE4451d

Revision v7 of 15 in this series.

Revisions (15)
  1. v7 [diff vs current]
  2. v7 [diff vs current]
  3. v7 current
  4. v7 [diff vs current]
  5. v7 [diff vs current]
  6. v7 [diff vs current]
  7. v8 [diff vs current]
  8. v9 [diff vs current]
  9. v9 [diff vs current]
  10. v9 [diff vs current]
  11. v9 [diff vs current]
  12. v10 [diff vs current]
  13. v11 [diff vs current]
  14. v11 [diff vs current]
  15. v11 [diff vs current]

[PATCH v7 0/9] ARM: VDSO

From: Nathan Lynch <hidden>
Date: 2014-06-27 17:01:12

On 06/27/2014 04:46 AM, Russell King - ARM Linux wrote:
On Fri, Jun 27, 2014 at 11:41:46AM +0200, Ard Biesheuvel wrote:
quoted
It appears that the EF_ARM_ABI_FLOAT_[SOFT|HARD] defines are just renames of

#define EF_ARM_SOFT_FLOAT       0x200
#define EF_ARM_VFP_FLOAT        0x400

so perhaps use those instead?
Or maybe provide our own definitions so we're not reliant on the host
environment providing the correct definitions for these.
Right.
quoted
quoted
This is what really concerns me about the VDSO.  It adds an additional
dependence on the C library in order to build the kernel.  What if you
don't have a C library in your cross-build setup (I don't.)
This is a host tool, so this is about the host libc not the target libc.
It still sounds pretty fragile.
Since removing -lgcc from the link (one of the changes from v6 to v7), I
believe the VDSO is not asking more of the toolchain or build
environment than the rest of the kernel does.  I have definitely built
it without a target libc.  Apart from the host program's use of
too-recent ELF constants (now fixed), I would appreciate help
identifying any remaining sources of fragility.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help