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

[Dan Cross via COFF]

On Sun, Oct 25, 2026 at 8:38 PM Douglas McIlroy via COFF <coff at tuhs.org> wrote:
> 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.

Curiously, ELF has the expressive power to produce a loadable
executable object file that could operate in the way you expected at
load time, but I think you're right that it probably can't split a
single variable across multiple sections at build time.

For those who are unfamiliar, ELF divides the world into sections and
segments; to a first order approximation, sections are used at build
time, consumed by linkers, debuggers, disassemblers, and the like.
Segments are used at load time by the OS or program loader. Segments
are far simpler than sections, and are defined by a simple data
structure called a, "program header."  Among the data a program header
includes are load addresses, file offset, type, flags, permissions,
and the segment's size.  The last is interesting, because there are
_two_ sizes: the "file size" (p_filesz) is the size of the segment's
contents in the executable file, while the "memory size" (p_memsz) is
the amount of memory the segment uses.  If the program header has
`p_memsz > p_filesz` for a loadable ELF segment, then the segment is
understood to consist of both initialized data and uninitiated data;
this is how ELF defines a .BSS segment; the delta is filed with zeros
at load (or CoW's a zero page or whatever).

Thus, one could imagine Doug's large array appearing in a dedicated
loadable segment, with filesz == 8, and memsz in the giga-range
(though I suspect that `p_filesz` might be rounded up to a page size,
regardless). But an ELF linker is allowed to rearrange and combine
segments; for example, grouping all of the executable text into one
segment, while moving all of the BSS spans into a dedicated `.bss`
segment with filesz==0; GCC can't know that this won't happen at
compile time, so if it sees a single data filled into a large,
otherwise uninitialized, array, then it hedges its bets and puts it
all into the same segment in its object file.  And of course, there
could be multiple such values, straddling the boundary between init
and uninit data; but any given segment can only have, since it only
has one boundary for it to straddle; without explicit annotations, the
compiler can't know what to do with any one of them.

However, one _could_ rewrite the ELF binary after linking to juggle
segments around to accommodate this, but I doubt that's common, and it
wouldn't help compilation.

        - Dan C.



> 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