Re: Help- selective symbol exposure after link in ELF/DWARF

Dave Lloyd <Dave@occl-cam.demon.co.uk> wrote:
> ... 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).


I, for one, would like to know _exactly_ which limitations you are speaking
of. (Just concrete specifics please.)


>> 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.


I agree that these are all real problems.


> ELF/COFF are compromises from the system architect listening to the
> complaints of the compiler architects (mostly now C++)


COFF was entirely less than optimal. I think that's pretty clear. ELF
on the other hand is not bad at all, and certainly not as bad as you
make it out to be.


>... - ending up with hacks like .ctors in gnu's ld...


I came up with the idea of using .ctors and .dtors sections to
implement g++ under ELF, and I don't see it as a ``hack''. Quite the
contrary. ELF supports sections. I used that feature (in what other
people have praised as an elegant way) in order to implement the C++
language in an efficient manner.


When I did my original work (at least) and perhaps even now, today,
in the present era, the GNU linker didn't have (or need) any special
knowledge of the .ctors or .dtors sections. In other words, having
the g++ compiler use those sections didn't have any effect on the
linker at all. Why? Because any decent ELF linker is _supposed_ to
do what I asked the GNU linker to do with the .ctors and .dtors sec-
tions... i.e. just glue them together... nothing more, and nothing
less. (Well, OK. Linkers are expected to do final relocations too,
but we here all know that. That goes without saying.)


>... (this tool can't even handle objects not generated by gnu's
>own BFD library gracefully, so much for robust software engineering).


I certainly would agree with you 100% that the quality of the code in
the GNU linker leaves a lot to be desired. There's no question about
that. What Can I say? I certainly won't defend the quality of the
GNU linker (in particular) because, quite frankly, I didn't write it.


But just because you found *one* rather buggy linker that *purports* to
fully support ELF (but which may actually have a lot of bugs which only
get revealed when you throw something at it that _didn't_ come from a
GNU compiler) I don't think that that alone is an adequate reason to
condemn the ELF object file format. I disagree with you there.


ELF is a good general-purpose object file format. It's cleaner and more
well designed than any other object file format which has EVER seen wide-
spread use. If you wish to assert otherwise, then please do provide some
specific complaints about ELF, rather than just non-specific complaints
about one particular _linker_ that claims to support ELF.


>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.


I hack compilers assemblers, linkers and debuggers for a living, and I
_still_ haven't the vaguest idea what you are talking about when you
say ``binds symbols to symbols, rather than to sections''.
Can you elaborate further on this.?


>Sorry for the rant, but my job has never been harder than on Unix where
>C defines the behaviour of *everything*.


If _that_ bothers you then take my advice and DO NOT become a CPU
designer. (In case you haven't noticed, an awful lot of the behavior
of an awful lot of recent CPUs has also been defined by C. This isn't
a strictly UNIX-based phenomenon either. Ask Microsoft what WindowsNT
is mostly written in.)


>Here is my wishlist for anyone
>working on linkers:
> (*) Define symbols against symbols *not* text (a section should
> define a symbol like any other)


I still haven't any idea what you mean.


> (*) Symbol expressions, being able to define section$begin and
> section$end and resolve something to section$end - section$begin is
> invaluable.


In many cases crt1.o and crtn.o provide ``frontspieces'' and
``tailpieces'' for specific sections, so I don't really see what you
think you need that you can't already get.


> (*) Resolve by indexing through a fixed mapping table (damned useful
> for types)


Sorry, don't understand what you're getting at.


> (*) 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.


Not clear what you're collating here -- names, sections, something else?


> (*) 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).


C++ now has namespaces. I agree that it would be nice to have some support
for those at the link level, but what kind and how? The devil(s) are in
the details. If you have some concrete and specific ideas, why not throw
them out?


> (*) Members are pulled out of archives only when a symbol they
> define is needed.


Do you know of linkers which do otherwise??? If so, please tell me so
that I can avoid using them.


> 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).


Sorry. I'm not that kind of guy. :-)


But seriously, this is another case where I haven't any idea what you think
you need to do or even why. How about a concrete example?


> (*) Type checking even of the simple form of comparing two integers.
> (We use a canonical numbering for our compositor).


I agree 100% that this has been *the* single most embarrasing failing
of all linkers over the entire time I've been in this business. As I
just noted in a separate posting, this *could* be implemented in many
linkers where it is not now implemented, and the type-checking *could*
be entirely based upon the available symbolic-debugging information.
Why that hasn't been done is obvious I think. Nobody ever got
motivated enough to do it. But it is definitely technically
deasirable and it definitely should be done. When somebody finally
offers somebody some bucks to do it, it will happen.


[Plus ca change -- I used linkers 20 years ago that did type and
argument checking. It's not rocket science, dunno why it hasn't
caught on. I suspect that in the Unix world, people assume that since
you have lint, why duplicate its function in the linker? (The answer
is "because you use the linker every time".) -John]


--

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