Split up debug-link and build-id debug info into separate classes to
make boundary between them more obvious.
When searching for a debug file in the "same dir" search location,
ensure its not a symlink. (user never explicitly signaled
that they trusted the directory, they only tried to import a file from
there.)
In e0aae02, the `++` was dropped from the index reference in this loop, but
that means the first item on each row of an integer array is incorrectly
repeated.
Restore the ++ so the array index is incremented across the line.
The machine type in an a.out header names a processor, not an operating system,
so targets sharing one cannot be told apart from the file. In binutils BFD,
an M_386 a.out can be BSD, Linux, or Mach etc, whose TEXT_START_ADDR
is either 0, 0x1000 or 0x10000
(bfd/i386bsd.c, i386linux.c, i386lynx.c, i386dynix.c, i386aout.c, i386mach3.c).
This can't be resolved from just the a.out header, so offer it as an option
(mirroring ElfLoaderOptionsFactory).
The existing Base Address option does something different. It shifts the section
blocks, symbols and the relocation patches together, whereas text base moves
only the blocks: symbol addresses subtract the block starts, so it cancels
out, and relocations resolve against the block starts.
The a.out format doesn't include a .text base/load address, so it has to be
derived based on magic type and platform.
This is what the N_TXTADDR macro in binutils does, and as its
comment says "This is getting very complicated. A good reason to discard a.out format
for something that specifies these fields explicitly". See:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/aout/aout64.h;hb=HEAD#l100
Most platforms load .text at 0; SunOS and NetBSD load it one page up, presumably to keep
the zero page for null pointer traps.
The a.out loader currently implements some of the logic, but differs on
SunOS 4 ZMAGIC, which loads at page 1 for executables, but 0 for shared libraries.
The only way to detect the difference is to infer it from the entrypoint
address, as binutils does: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/aout/sun4.h;hb=HEAD#l54
This means a SunOS 4 executable was loaded at 0 even when it described
symbols in the 0x2000 range.
Similarly NetBSD changes to match binutils: OMAGIC, NMAGIC and CMAGIC now get 0
(netbsd.h overrides TEXT_START_ADDR, not N_TXTADDR)
loadSymbols adds n_value to the start of the block the symbol belongs to, but
n_value is an address (see https://man.freebsd.org/cgi/man.cgi?a.out(5) ),
not an offset into its segment, so we need to subtract the segment's base.
In most cases `determineTextAddr` is 0, so they are the same for the .text
segment, which is why function symbols still loaded fine. But for the
.data and .bss segments they don't, so their symbol locations ended up shifted.
