[COFF] [TUHS] Re: What does `ld` stand for?

[Douglas McIlroy via COFF]

Branden wrote on TUHS:

> I ... recommend David Salomon's "Assemblers and Loaders".
> When I got through the latter's giant chapter on assemblers,
> many things fell into place for me.

This conjured the memory of a learning experience with ELF,
which usually flies under the radar.

Gcc took remarkably long to compile a program that included
a fragment like this:

        define N 1<<15
        static struct { bool h:1;  bool v:1; } hv{N]{N] = {{1,1}};

Apparently there is no way to tell ELF to place a given data section
next to an uninitialized section, so gcc had to instantiate the whole
1GB array in the object file, when I had imagined it would take at
most 8 bytes plus a few words of metadata.

Doug

On Sun, Oct 25, 2026 at 5:50 PM G. Branden Robinson via TUHS
<tuhs at tuhs.org> wrote:
>
> At 2026-10-25T10:42:45-0700, christopher fujino via TUHS wrote:
> > My friend, taking an OS course was wondering what `ld` stood for.
> > After doing an online search, concluded "no one knows." Surely someone
> > around here must remember why the linker is called `ld`? Thanks!
>
> At 2026-10-25T11:08:51-0700, christopher fujino via TUHS wrote:
> > It looks like the earliest source for `ld` I can find on TUHS is from
> > v2:
> > https://www.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/ld1.s
> >
> > / ld1 -- link editor
> >
> > Could it stand for "link editor"?
>
> At 2026-10-25T13:40:04-0600, Warner Losh via TUHS wrote:
> > The first edition manual is at
> > https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man1/ld.1
> >
> > And says the same thing. As do later editions.
>
> In my own education I found myself scandalzied by the meager emphasis
> given to linking and loading in the curricula offered to those receiving
> university educations in software engineering and/or computing science.
>
> I suppose this is because there is thought to be no "deep theory" behind
> linking and loading techniques, at least not enough to sustain a steady
> research program.  Coming up with object file formats and linkers and
> loaders to produce and consume them is, after all, a "simple matter of
> programming".
>
> But I wonder.  We don't seem to have a deep theory of operating systems,
> but that discipline does, just barely, sustain a research program.
>
> Not that industry seems to realize it, however.[1]  Once one has
> achieved "world domination",[2] little of interest remains except
> increasing returns to the dominators' capital.
>
> I second recommendations of John Levine's book, and also recommend David
> Salomon's "Assemblers and Loaders".  When I got through the latter's
> giant chapter on assemblers, many things fell into place for me.
>
> Regards,
> Branden
>
> [1] https://microkerneldude.org/2022/02/17/a-story-of-betrayal-csiros-war-on-ts/
> [2] https://www.computing.co.uk/news/1831329/linux-promises-world-domination