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

[Warner Losh via COFF]

On Sun, Oct 25, 2026, 8:44 PM Dan Cross via COFF <coff at tuhs.org> wrote:

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

Two comments. Setting the array = {0} makes it initialized so no split
between sections. And there are also flags that control the alignment of
the sections (or you can use a custom linker script).

Warner

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