[gentoo-user] Rethinking binfmts [WAS: How the HAL are you supposed to use these files?]

2010-02-17 Thread Enrico Weigelt 
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
--

Re: [gentoo-user] Rethinking binfmts [WAS: How the HAL are you supposed to use these files?]

2010-02-17 Thread Volker Armin Hemmann 
On Mittwoch 17 Februar 2010, Enrico Weigelt wrote:

 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.

man make.conf:

   splitdebug
 Prior to stripping ELF etdyn and etexec files, the 
debugging info is stored for later use by various debuggers.  This
 feature is disabled by nostrip.  For installation of 
source code, see installsources.

http://phajdan-jr.blogspot.com/2010/02/how-to-get-useful-backtraces-almost-
for.html

http://www.gentoo.org/proj/en/qa/backtraces.xml

With splitdebug enabled, Portage will still strip the binaries installed in 
the system. But before doing that, all the useful debug information is copied 
to a .debug file, which is then installed inside /usr/lib/debug (the complete 
name of the file would be given by appending to that the path where the file is 
actually installed). The path to that file is then saved in the original file 
inside an ELF section called .gnu_debuglink, so that gdb knows which file to 
load the symbols from.

for someone so highly critical you should do some more reading.