1. 02 7月, 2021 1 次提交
  2. 11 3月, 2021 1 次提交
  3. 09 9月, 2020 1 次提交
  4. 17 8月, 2013 2 次提交
    • R
      fix detection of arm hardfloat · 4918c2bb
      Rich Felker 提交于
      it turns out that __SOFTFP__ does not indicate the ABI in use but
      rather that fpu instructions are not to be used at all. this is
      specified in ARM's documentation so I'm unclear on how I previously
      got the wrong idea. unfortunately, this resulted in the 0.9.12 release
      producing a dynamic linker with the wrong name. fortunately, there do
      not yet seem to be any public toolchain builds using the wrong name.
      
      the __ARM_PCS_VFP macro does not seem to be official from ARM, and in
      fact it was missing from the very earliest gcc versions (around 4.5.x)
      that added -mfloat-abi=hard. it would be possible on such versions to
      perform some ugly linker-based tests instead in hopes that the linker
      will reject ABI-mismatching object files, if there is demand for
      supporting such versions. I would probably prefer to document which
      versions are broken and warn users to manually add -D__ARM_PCS_VFP if
      using such a version.
      
      there's definitely an argument to be made that the fenv macros should
      be exposed even in -mfloat-abi=softfp mode. for now, I have chosen not
      to expose them in this case, since the math library will not
      necessarily have the capability to raise exceptions (it depends on the
      CFLAGS used to compile it), and since exceptions are officially
      excluded from the ARM EABI, which the plain "arm" arch aims to
      follow.
      4918c2bb
    • R
      support floating point environment (fenv) on armhf (hard float) subarchs · 7318c62e
      Rich Felker 提交于
      patch by nsz. I've tested it on an armhf machine and it seems to be
      working correctly.
      7318c62e
  5. 19 9月, 2011 1 次提交
    • R
      initial commit of the arm port · d960d4f2
      Rich Felker 提交于
      this port assumes eabi calling conventions, eabi linux syscall
      convention, and presence of the kernel helpers at 0xffff0f?0 needed
      for threads support. otherwise it makes very few assumptions, and the
      code should work even on armv4 without thumb support, as well as on
      systems with thumb interworking. the bits headers declare this a
      little endian system, but as far as i can tell the code should work
      equally well on big endian.
      
      some small details are probably broken; so far, testing has been
      limited to qemu/aboriginal linux.
      d960d4f2