Attempt to port PDP-11 LINKer to PC C/C++ — learning how the linker works, the hard way.
The code (partially) ported from MACRO-11 sources to C/C++. Port source: RT-11 LINK V05.45.
Currently the PCLINK11 links most of test OBJ files properly, but we have some troubles linking tests with libraries.
The source code is able to compile under Windows (VS2013), and also under Linux/MacOS (gcc/clang, use the Makefile).
Command line:
pclink11 <input files and options>
Options (both / and - prefixes are allowed):
/EXECUTE:filespec— Specifies the name of the memory image file/NOBITMAP/X— Do not emit bit map/WIDE/W— Produces a load map that is 132-columns wide/ALPHABETIZE/A— Lists global symbols on the link map in alphabetical order/SYMBOLTABLE/STB— Generates a symbol table file (.STB file)/MAP— Generates map file--version— Show the program version information--help— Show quick help on the command line options
Input files and options are space-separated.
Examples:
pclink11 HELLO.OBJ— link the object file, will produceHELLO.SAVexecutablepclink11 /MAP /SYMBOLTABLE /EXECUTE:LD.SYS LD.OBJ SYSLIB.OBJ /X— link object file with system library, produce map file and symbol file, save output asLD.SYS, do not put bitmap in the first blockpclink11 TEST1.OBJ TEST2.OBJ /MAP /WIDE /A— link two object files, generate map file with wide format, alphabetize list of symbols
Folder tests contains several dozens sub-folders with .OBJ files.
First, we use RT-11 simulator written by Dmitry Patronov to produce "etalon"/"original" output files, they renamed with -11 suffix — see !runtest11.cmd command file.
Then, we run the pclink11 with to produce "our" output files, they renamed with -my suffix — see !runtestmy.cmd command file and testrunner utility.
And finally, we compare "original" files with "our" files, line-to-line or byte-to-byte, using testanalyzer utility.
"Our" MAP files differs in the first line (program name, date/time, no page number), and there's no paging, so no page header lines. SAV/SYS/REL and STB files are binary, compared byte-to-byte, should be no differences. Log files are absolutely different, we're not comparing them, but in "our" log files we're looking for "SUCCESS"/"ERROR" and so on.
First priority:
- Fix bugs for the failing test cases
Second priority:
- Need more tests, currently we have 115 test cases
- Reduce amount of logging, add option for verbosity level
- Process other command-line options, including file-specific ones
Not implemented now, and not sure we will:
- Link for foreground execution with /R or /FOREGROUND option, produce .REL file
- LDA output — produce a file in absolute binary loader format
- Overlays
- Linkage with separated instructions/data spaces