[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
> 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
> (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.
Main Index |
Thread Index |