Re: libelf

[Jason Thorpe <thorpej%shagadelic.org@localhost>]

On Jan 15, 2010, at 12:00 AM, David Holland wrote:

>> What are the defects in Elf as you see them?
> 
> Most of it is in shared library handling. The biggest issue is that
> there's no way to specify transitive dependencies or coherence
> requirements, so you can end up with broken processes.
> 
> E.g. consider libcurses, which re-exports libc's FILE * type. This
> makes the libcurses ABI dependent on the libc ABI: a program using
> curses can get a FILE * from libc and pass it to curses, which then
> passes it back to libc.

Adding extra complexity in the object / shared library format to deal with bad 
ABI design isn't a particularly productive use of time, IMO.  In the particular 
example you cite, all of the problems can be eliminated by simply making FILE * 
a truly opaque type and hiding all of the internals behind real accessors / 
mutators, rather than the pseudo-opacity we have now (where the guts are 
actually exposed in header files and manipulated by macros).

(For the record, I admit to being guilty of bad ABI design myself, especially 
in the case of the bus.h stuff in the kernel... but I think we should strive to 
fix the problems that we inherited / created in this regard.)

> In this situation curses and the application
> need to be using the same libc ABI, or it blows up. In particular, if
> you make a change to the FILE * representation and create compat entry
> points in libc, both curses and the application must use either the
> new entry points or the old ones.

That isn't necessarily true if your compat entry points 

> However, making an annotation that says that the libc used by the
> libcurses client must be the same as the libc used by libcurses
> itself... that's not very hard. That would at least prevent broken
> binaries from running. (With ELF, they'll cheerfully run and exhibit
> undefined behavior.)

Actually, it would be fairly straight-forward to provide that annotation and 
warnings in ELF, using notes and some special processing of those notes in 
ld.elf_so. 

> A related problem is that if you bump the major version of libc and
> don't recompile curses (but do recompile some application) is that you
> can end up with load images that have multiple different libcs. This
> might in principle stand a chance of working (except that most malloc
> implementations will get confused by not having exclusive access to
> sbrk) if ELF didn't bind symbols willy-nilly by name regardless of
> what library they were supposed to be coming from. Which means that if
> you have a process with two different copies of libc in it, only one
> of them will actually be used, which *will* cause whatever wanted the
> other copy to do the wrong thing.

Again, this is something that could, in theory, be addressed within the 
framework of ELF.

> Meanwhile, on the feature side instead of the bug side: the other big
> thing we ought to have that ELF doesn't support is ResEdit. Why
> shouldn't you be able to e.g. edit the compiled-in paths in an
> executable, bind in images and change them later, or whatever? There's
> no need to adopt Apple resource forks (or any of their imitations) to
> get such functionality for executable files; executable files already
> have all the necessary structures and indexes. All it takes is some
> administrative reorganization and some strengthening of the way
> sections work. And keeping full relocation data in output executables,
> but that's no bad thing.

I agree there is no need to adopt Apple-style resource forks for this :-)  Even 
Apple agrees on this, to a certain extent (resource forks have been essentially 
abandoned for application resources in favor of application bundles, although 
bundles do have their down-sides as well).

But, again, lazy-loadable and editable resource sections are something that can 
be completely addressed within the framework of ELF (and Apple even does this 
for certain executables within the framework of Mach-O, mostly for code 
signing).

> (ELF is a "don't get me started" topic. Can you tell? :-/ )

I can... but I also don't think it's necessary to invent a completely new 
object format, at least not for the examples you have cited.

> Apparently so. There's no "format: flowed" in the headers here, or
> whatever the precise notation is, and there should be.

Weird.  I wonder if the @netbsd.org mailing lists are stripping it out... or I 
wonder if my Mail app isn't putting it there in the first place.  I'm using a 
different version of Mail to send this one, so let's see if it's any different.

-- thorpej