glibc 2.10 featuring new elf trick

Hi,

I just wanted to brought you attention to the glibc 2.10 changelog. Take a special attention to the bottom (to the 'Automatic use of optimized function' section). URL: glibc 2.10 news - Ulrich Drepper — LiveJournal
This seems to be a nice way to make fat binaries. Not in the apple lingo, but to make binaries with code optimized for different archs. This sounds great to, at least, bundle different versions of some functions like strlen and the likes.

Nuno

"Nuno Lopes" <nunoplopes@sapo.pt> writes:

Hi,

Hello,

I just wanted to brought you attention to the glibc 2.10 changelog. Take a
special attention to the bottom (to the 'Automatic use of optimized
function' section). URL: glibc 2.10 news - Ulrich Drepper — LiveJournal
This seems to be a nice way to make fat binaries.

IMO, fat binaries should go away and be replaced by LLVM bitcode, with
code generation performed by the OS at load time. This would have many
advantages: the compatibility with all current and future
architectures would be guaranteed, the code could be optimized at load
time to take advantage of specific features of the host (and even user
preferences), link-time optimization could happen with dynamic
libraries too, executable files would be smaller, assertions and other
debugging features could be turned on and off by the user, etc.

(But thanks for the pointer, nevertheless)

Michel.

Hello, Michael

IMO, fat binaries should go away and be replaced by LLVM bitcode, with
code generation performed by the OS at load time. This would have many
advantages: the compatibility with all current and future
architectures would be guaranteed,

Unfortunately no, the IR obtained from languages like C, C++, etc is
not target neutral.

But LLVM IR is neutral* for the various processors of a given processor family for the given target (e.g.Intel core processors with and without SSE 4.1)

Nit: you can’t use the same bitcode file for both 32 and 64 bit mode x86 compilations either, I presume.

Cheers,

David