Re: Why do we still assemble?

hbaker@netcom.com (Henry G. Baker) writes:
> [RS/6000 compilers disassemble their object to get .s files]
> What an inspired and elegant solution! Any decent system has to have a
> good disassembler, anyway, so it's better to put good manpower into this
    ^^^^
> task than into writing an assembler.


bill@ssd.csd.harris.com writes:
>Well... I don't consider this a very elegant solution, myself. First of
>all, I lose all the local labels and symbols that the compiler generated
>and used but which don't get into the object file.


I think the operative word here is _good_. Most object file formats I
have seen include both file-scoped and global symbols, so there is no
reason why the local labels and symbols shouldn't be there in the -S file.


>Also, disassembling a relocatable object file is not always the same as
>disassembling an executable...


(Ah hah! Therein lies a whole 'nother discussion.) And why is this?
Because linkers don't do what they promise to do. My very first computer
job in 1963 was fixing the misfeatures of an IBM linker. >From everything
I have seen, linkers haven't improved even one smidgeon in the mean time.


If I link modules A & B, the linker should combine the two modules and
merge their symbol tables, and resolve the linkages from A to B and those
from B to A. But the result should still be linkable with additional
modules. At any point, the linked modules should be _loadable_, at which
time any relocations are applied.


So we have 2 completely separate operations -- linking and loading. Let
me represent linking by the infix symbol ';', and loading by the symbol
'.'. Then, ';' should be an _associative_ operation, so that (A;B);C. =
A;(B;C). = A;B;C.


I can't claim to have examined a huge number of Unix linkers, but some
that I've seen have a '-r' option all right, _but it doesn't do anything_!
It simply concatenates the files together, and doesn't perform any linkage
at all.


Due to the 40-year-old brain damage of only a 2-level naming system,
linkers also need to provide an additional set of 'parentheses/brackets'
'[]' such that resolved names inside the brackets are stripped (e.g.,
become 'file-scoped' instead of global) leaving only unresolved names to
be linked. Thus, [A;B];C. would represent a linkage of A with B, and C
could bind only names left unresolved from the [A;B] binding.


I can't tell you the number of times I've taken a perfectly good program
and upgraded it to a new version of an operating system/set of libraries,
only to have it fail because its external names were (now) conflicting
with (new) names in the newer libraries. Most linkers provide you with no
way to handle this, so I have to recompile my program and change my names.
Since I have no way of predicting what names future releases of these
libraries will utilize, there is currently no way to protect my software
from these future changes. Notice, I am not worried about routines that I
explicitly call myself, but about essentially _internal_ names for
communication from one library routine to another library routine. Can't
these guys talk to each other without bothering my software?


Ada's packages handle this problem pretty well, and Ada9X's sublibraries
are even better. I can imagine, however, that the implementors have to
stand on their heads to get this stuff to work with the crufty linkers out
there.


--

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