Slashdot Mirror
GNU C Library 2.17 Announced, Includes Support For 64-bit ARM
hypnosec writes "A new version of GNU C Library (glibc) has been released and with this new version comes support for the upcoming 64-bit ARM architecture a.k.a. AArch64. Version 2.17 of glibc not only includes support for ARM, it also comes with better support for cross-compilation and testing; optimized versions of memcpy, memset, and memcmp for System z10 and zEnterprise z196; and optimized version of string functions, on top of some quite a few other performance improvements, states the mailing list release announcement. Glibc v 2.17 can be used with a minimum Linux kernel version 2.6.16."
Best guess I have is that they removed their implementations of the *at syscalls added in 2.6.16 (since almost no one is using that old a kernel anyway and presumably it made the maintenance easier), and will always directly make use of the kernel versions of those. There were a few other syscalls added in 2.6.16, so it might be related to one of those instead (but the *at ones look most likely to me).
really don't understand why a few people here attack anything to do with Linux. Linux is different, not a threat.
It is a threat. A threat to MS developers, a threat to MS shareholders, a threat to those who earn their living cleaning malware off of folks' computers.
For the rest of us, though, it's a blessing.
Free Martian Whores!
Looks like the eglibc fork was a good thing for the project. Rather than having one maintainer that resists and fights an architecture for personal reasons, the project is now being proactive in integrating a new ARM architecture.
Now if we could only get away from having so many Android-only bionic-targeting blobs.
From the release announcement:
* Port to ARM AArch64 contributed by Linaro.
From that organization's website:
"it wants to provide the best software foundations to everyone, and to reduce non-differentiating and costly low level fragmentation."
"Linaro was established in June 2010 by founding members ARM, Freescale, IBM, Samsung, ST-Ericsson and Texas instruments (TI). Members provide engineering resources and funding. Linaro's goals are to deliver value to its members through enabling their engineering teams to focus on differentiation and product delivery, and to reduce time to market for OEM/ODMs delivering open source based products using ARM technology."
(member list quite a bit longer than above names)
In other words: many commercial enterprises, that are in it for the money and fighting each other in the marketplace, but working together to improve something that's out there in the open, free for all to use. So that what's common to all, is the best it can be, and each vendor can focus its resources on what makes their product different from the rest of the pack.
Sigh - how much better life could be if that principle were applied more often...
For those of you trying to figure out what he's talking about, here's a list of *at syscalls.
http://linux.die.net/man/2/openat
Notice at the bottom of the page the group of similar file access system calls ending in "at". So for handling files with certain kinds of paths you use openat() instead of open()
I learned something.
Cwm, fjord-bank glyphs vext quiz
I'm trying to undo an unfair mod I applied to an insightful post. Slashdot should let us (at least for one minute) undo a mistaken mod :(
you spend your time dicking with things that were solved 20 years ago but everyone thinks they need to reinvent and do differently without ever asking why it should be done differently in the first place. Its no more a blessing then any other mental illness, you just don't recognize it.
Well, wooden wheels were first.. eventually metal with tires... as materials improve, sometimes re-inventing the wheel becomes a good idea...
Michael J. Ryan - tracker1.info
In fairness, this is complicated a lot by two issues:
1. Many of the optimizations that help things like memcpy, memcmp, etc. are utterly wrong and backwards in any loop that actually DOES SOMETHING in its body; they only end up being optimal in the degenerate case where everything but the load and store is loop overhead and the optimal result is achieved by eliminating overhead. And on some CPU models such as most modern 32-bit x86's and some 64-bit ones, the optimal result is actually attained with a special instruction that's not usable in general for more complex loops (i.e. "rep movsb"). Factors like these make optimizing these specific functions in the compiler a task that's largely separate from general-case optimization, and when the main target libc is already providing the asm anyway, there's little demand/motivation to get the compiler to do something that won't even be used.
2. Distros want a binary library that can run optimally on all variants of a particular instruction set architecture. Relying on the compiler to optimize functions for which the optimal variant is highly cpu model specific would only give a binary that runs optimally on one model, unless a lot of logic is added to the build system to rebuild the same source file with different optimizations. This is not prohibitively difficult, but it's also not easy, and it's not worthwhile when the compiler can't even deliver the desired optimization quality yet.
Overall I agree that machine-specific asm in glibc (and elsewhere) is a disease that results in machine-specific bugs and maintenance hell, but when there are people demanding the performance and pushing benchmark-centric agendas, it's hard to fight it...
It's not so simple for two reasons:
(i) Builtins are used only when gcc wants to inline their code. This may not always be the case. Their usage may (I think) also depend on the nature of the arguments (e.g., are they constant? is their length known? etc.). And there are other weird cases (passing memcpy() function pointer or whatever). Even if you don't explicitly disable builtins, your program may call these functions.
(ii) This specific part of the announcement concerns ifunc-related optimizations. This means that the version appropriate (most optimized) for the processor the program is _currently running on_ is chosen at runtime. In x86 world, at runtime (during the first call to the function), a SSE4-enabled function may be chosen over default function if the processor supports SSE4, for example. And you have just a single binary of your program to handle.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams