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."
I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library.
Because it relies on the kernel API compatible with 2.6.16 and later.
The Hurd project isn't mentioned anywhere in the mailing list post.
It's my understanding that the Hurd project uses a customized version of glibc.
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!
is not gonna be happy
Do you even Assembly?!
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...
He must have accidentally it. The whole thing!
Oh man so I went multiarch on Debian for nothing
Linux is no threat to anyone, its just an excuse people like to use.
Programers, even MS ones can move elsewhere. Linux won't 'take over the world' ever if the $7/hour programmers can't write code for it. Most companies are unwilling to spend large sums of money for programmers who have their head up RMSes ass and think they're worth ridiclous sums of money, so its not a threat. Programming isn't all that difficult if you have the proper info. Not everyone can deal with the requirements of C, but then thats why you see companies like Google coming up with new languages to solve that problem so they can waste less time with programmers who are meticulous about memory management and more time getting shit done.
MS Shareholders, meh, thats debatable. MS writes apps for other OSes already and makes a fortune off of them, hell Office is the best Office for OSX, Apple doesn't even bother making a truely competing product. Pages/Numbers are like MS Works, not Office. If the world really did jump ship to Linux, they'd move Office over as well. They aren't going to go out of business of some political ideal, thats what Linux people do. MS will follow the money, everything they do is about the money. Right now its more profitable to spend some of that money keeping people on Windows, but if that changes they won't roll over and die.
If Linux became main stream, it would just get malware as well. You don't need to exploit a machine to get malware on, you need to exploit a user. Its been easier to exploit users than it has been to exploit windows since AT LEAST XP SP2, probably a little before that. Windows Vista dropping admin as default pretty much ended the easy way to get an entire machine. But why do you need an entire machine? You don't. You just need to be able to run apps, and the less intrusive you are the longer you'll go without being detected. Windows gets targeted due to market share. Android sees some of the same issues due to its popularity, but lets not recognize that and pretend its perfect, shall we? Windows users don't notice malware until they've got 900 different variants installed that do something like change their home page. You are no different just because you run Linux. You wouldn't notice intelligent malware any faster than a Windows user would, you just think you are immune. You probably aren't stupid enough to download the wrong thing most of the time, but I'd be a months pay that you've only not been caught in a malware scam by dumb luck and obscurity. Eventually, something will come through that is so close to legit looking that it will/has got you and the only thing that stopped it was that it wasn't targeting your OS. Thats only because you're OS isn't popular enough to waste their time on, not because its saving you.
For the rest of us, though, it's a blessing.
While some people prefer to live in a world of obscurity (thats not exclusive to Linux fanboys btw, you aren't any more original than goths), its rather silly to call it a blessing. Instead of removing malware 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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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
The mailing list post says it is used '... in GNU systems, and is careful to also say '... most systems running the Linux kernel ...', from which I infer that they're two different things. If GNU systems doesn't mean the Hurd, then what would it mean?
Besides Linux there is at least one variant of BSD to add to the GNU family mix. Note on the same page there is an OpenSolaris flavor too.
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
although with all the chaos around with armN means for various N, who knows.
mmm, AIUI aarch64 has NO asm level compatibility with 32-bit arm architectures so having build systems treat it as a completely unknown architecture (and hence using the generic C implementations) rather than treating it as a variant of arm (and hence trying to use arm assembler routines and failing to build because of it) is probablly a good thing
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
When it comes to code, 99 times out of 90, starting over is a stupid idea. You don't throw out the idea of a toilet in space, you refine the toilet to work in space based on existing tech and new requirements. A space toilet works a lot differently, but its not a re-invention.
Linux audio is a perfect example of needless reinvention. OSX and Windows both seem to have no problem with one sound system even with apps that require very low latency and supporting audio in general yet Linux has how many different sound daemons? And none of them do more than one task worth a damn if they even do the one profile they were 'designed' for.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The non-builtin ones are typically used for large arguments for memcpy. I'm not familiar with the GCC implementation, but LLVM's memcpy() optimisation knows roughly the cost of a call to memcpy() and will use a sequence of inline loads and stores to avoid the call, but will just call memcpy otherwise. The reason for this is better instruction cache usage. A call to memcpy() requires saving any caller-save registers (this can be cheap, as the register allocator will try to put temporaries that are not used after the call in these registers, so that they don't need to be saved), putting the arguments in registers (this is quite cheap, as they've typically just been used and so the register allocator will try to ensure that they're in the correct registers already), or on the stack on x86 (not too expensive, as push and pop are really register-register moves on modern chips), and of loading the arguments back. For memcpy(), the cost of a single L2 cache miss in the src will likely dwarf the cost of a slow implementation, so it's worth sticking prefetching in very early, if you can. The memcpy() call in position-independent code will be indirect, which means that it will take up an entry in the branch predictor's table. These are a relatively scarce resource - you have something like 512 of them on a modern processor - at each call site.
The ifunc stuff is not necessarily a win, for the same reason. It turns every memcpy() call into an indirect call (or a double-indirect call in PIC), which means that it now needs to go through the branch predictor. This is the kind of thing that is a clear win on microbenchmarks, but has the potential to make real code slower: each ifunc costs either a branch miss (pipeline stall and flush) or a branch target buffer entry (slowing down some other code). Or, in really bad cases, both, because it and another hot function end up trying to use the same BTB entry so you always get a branch miss for both.
I am TheRaven on Soylent News