Alan McKinnon wrote: > Why is ELF so prone to bloat (or more accurately why do so many > compilers generate such large libs?)
Yes, that's an really good question. ELF has many things, that are IMHO not really necessary or shouldn't even be used. For example, debugging information doesnt need to exist within the binary itself. An external file would be fine, too, and allows removing them by standard file operations. Another redundant thing is exec()'ing the dynamic linker from userland: the kernel could load it along with the usual segments. There could even be a default kernel-land dynamic linker (for the 99.9% cases where no special linker is needed), it could cache a lot of stuff. If I were to design a new binfmt, it would look like this: * Magic + file size + file hash * userland linker filename (may be empty) * 4x segment descriptor: -> packed-size, real-size, offset, encoding (compression,etc) -> #0: code, #1: data, #2: symbol table, #3: unused * imports-list: virtual library name + namespace-id * entry point (relative to code segment) * symbol table (possibly compressed) * [.. segment data ..] ... All binaries would be libraries (no distinction at all), everything's relocatable, entry points are executed in the from leafs to root of the dependency tree. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
