Re: Help- selective symbol exposure after link

Paul David Fox <pfox@lehman.com> wrote:
> > The real problem is that C doesn't need it and has no ability to
> > express this layer of scope. With languages like Algol 68, Fortran 90,
>
> Oh yes it does! C does need it. If C had it then we could write
> portable shared libraries. Have you ever looked into how difficult and
> pathologically different every Unix system is when it comes to
> shared-lib bindings?


C needs it adding to the language, oh yes. (But then C needs so much
doing to it) But you don't need such a facility to correctly implement
C and F77, oh no. And I've just spent most of this year grappling
with the limitations of ELF (a classic example of a highly generalised
format capable of nothing). We've given up on shared-libraries under
Unix - too expensive and unportable at least for this release.


> Why oh why do the compiler people ignore the linker?


The trouble is noone can agree whether the linker comes with the
compiler or the system. The system architect designs a linker to link
the system calls together and nothing else (a.out) while the compiler
architect has to worry about compatibility with objects from other
compilers (users will not put up with a single language environment)
and so has to plumb for the LCD. ELF/COFF are compromises from the
system architect listening to the complaints of the compiler
architects (mostly now C++) - ending up with hacks like .ctors in
gnu's ld (this tool can't even handle objects not generated by gnu's
own BFD library gracefully, so much for robust software engineering).
For all the flaws in its format (1k records etc) the old Intel OMF (as
used by DOS and OS/2) is not bad - it at least provides groups and
binds symbols to symbols not sections. The Inmos linker (TCOFF) had
great potential but I don't think they ever implemented more than the
bare minimum needed by their C compiler making it worse than the rest
in that it promised so many things but working out what it would
actually deliver was a nightmare. At least you could equate arbitrary
symbol expressions (you can't even equate symbols with ELF).


Our and others' solution is to treat the system object file as "raw
binary" and use our own compositor (intermediate linker) to do the
interesting bits. Still a pain in the arse though.


Sorry for the rant, but my job has never been harder than on Unix where
C defines the behaviour of *everything*. Here is my wishlist for anyone
working on linkers:
        (*) Define symbols against symbols *not* text (a section should
        define a symbol like any other)
        (*) Symbol expressions, being able to define section$begin and
        section$end and resolve something to section$end - section$begin is
        invaluable.
        (*) Resolve by indexing through a fixed mapping table (damned useful
        for types)
          (*) A defined collating order and ability to control that from the
        object (some lds lets you do some of this with a link-script) with
        frontispieces and tailpieces around whole sections.
        (*) Namespaces for symbols (this can be handled by defining unique
        global symbols such as fred$joe, but it helps if the linker
        understands this particularly when reporting errors).
        (*) Members are pulled out of archives only when a symbol they
        define is needed. Full minimum coverage also needs some members
        pulled in when they reference certain symbols that have been defined
        (you do need to go both ways).
        (*) Type checking even of the simple form of comparing two integers.
        (We use a canonical numbering for our compositor).
... and a good few more as well. Simple principle: you should be able to
do anything in the binary object that you can do in a link-script.


Cheers,
----------------------------------------------------------------------
Dave Lloyd mailto:Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd http://www.occl-cam.demon.co.uk/
Cambridge, England http://www.chaos.org.uk/~dave/
--

Return to the comp.compilers page.
Search the comp.compilers archives again.