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

"Ronald F. Guilmette" <rfg@monkeys.com> writes:


>Dave Lloyd <Dave@occl-cam.demon.co.uk> wrote:


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


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


Yes, the GNU linker still does nothing special with the .ctors and
.dtors sections.


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


Well, if you find bugs in the GNU linker, report them, and they will
get fixed. If you don't report them, then they most likely won't get
fixed. The GNU linker is free software. I hope you don't think that
there is some team of people working on polishing it. There are a few
people working on getting the linker to do what they want for their
projects, and, currently, there's me trying to coordinate the changes
in, as the saying goes, my copious spare time.


In fact, I frequently test the GNU linker with the output of other
assemblers. I'm scarcely going to claim that it's perfect, but in my
experience most problems arise because the other tools are generating
objects that do not conform to the ELF ABI. The Irix 5 tools, for
example, were particularly bad in this regard, and forced various
hacks on the MIPS ELF backend of the GNU linker for the sake of
compatibility.


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


I have to agree with this. It would be folly to judge ELF on the
basis of an implementation. ELF is the best object file format that I
know of. I'm sure it would be possible to design a better one, and I
encourage anybody interested to do so. Don't be surprised if it
doesn't take the world by storm, though.


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


Actually, I believe this feature can be helpful in certain cases, and,
in fact, the GNU linker provides this capability. If the name of a
section can be a C symbol (sorry, more C centrism; in practice this
restriction means the symbol name doesn't contain a `.') then the
linker automatically defines symbols representing the start and end of
the section.


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


Assuming you are collating sections, then I think most linkers,
certainly including the GNU linker, have link scripts as you describe.


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


One time you want to do this is when you have an initialization
routine that should only be linked in if certain other symbols are
referenced. The GNU C library does this sort of thing using ELF. I
believe the library startup code looks through a section and invokes
every symbol found. Functions which require initialization define the
initialization function in that special section.


If you have some other use for this operation, what is it?


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


The Irix 6 64 bit MIPS ELF ABI has definitions for how to do type
checking in the linker, but I don't know if the Irix 6 tools actually
use them.


It would certainly be possible to use the symbolic debugging
information for this operation, but it would slow down the linker.
That's not a reason not to do it, of course.


In fact, the GNU tools have all the necessary bits to do this checking
with the symbol debugging information. There is code to read the
debugging information into a standard internal format (DWARF has not
been implemented, though stabs, COFF, and IEEE have been). This
format could easily be used for type checking of functions and
variables. If anybody feels like working on this, contact me.


>[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]


That's an answer that cuts both ways. You use the linker every time,
therefore you want it to be as fast as possible. (The last time I
went through an optimization cycle on the GNU linker, it was primarily
disk bound, and I hope it still is.) Time spent parsing the debugging
information and checking the types of functions is time added to the
compile/link/debug cycle.


Ian Taylor
ian@cygnus.com
--

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