|
ELF Format Weaknesses? Ideas for a new file format?
Hello,
I've been noodling on the slow startup problems with KDE and other massive C++ projects, and I think I've come up with a generalized solution in the form of a packed PATRICIA trie as a symbol table. I have a more compact representation that I'm going to benchmark against the PATRICIA, but that's a different topic.
What I want to know is, are there any other weaknesses that others have encountered in the ELF file format? One of the original problems was lack of a platform specifier, which led the OpenBSD folks to develop "OLF" for a while, but which was resolved by annotating the ELF file in a specific way. FatELF makes ELF binaries fat, of course.
Are there other problems with ELF? Are there issues with the way that the file format is structured, that could be fixed by a different binary format? Specifically, are there issues inherent to the way the file format lays out sections that could be rearranged to make the representation easier and faster to load? Are there better ways to do PLT vs. GOT representations for 32 and 64 bit targets? Is there a way to reclaim %ebx (yeah, x86-specific)?
One thing that I'm thinking about is how to support more modern linkage schemes. The flat symbol namespace seems to me to be a hindrance to proper package and library construction. Of course, flat tables could be created which aliased a hierarchical scheme, to provide compatibility. How about a compact, efficient representation of data types in an object file, which can possibly be reflected upon by a language with those facilities?
Variant functions (for instance, a bog-standard implementation of a routine for i386, but one which uses all the newest whiz-bang vector instructions for a more modern CPU, existing in the same library, referenced by the same name, but bound at load time based upon what the kernel tells the loader the current platform is...)?
One feature I'm also thinking of is a "forward-only" load-time symbol resolution flag, which should make library interposition easier and more automatic, without having to resort to dlsym(RTLD_NEXT,...).
How about application bundles? A read-only filesystem within the bounds of the executable itself, for packing resources? Tunable knobs tucked into the binary itself, available to a program via a simple API?
I'd be interested to know what kinds of features folks would like to see, and what they'd consider useful attributes in a forward-looking file format.
|
