Enable debug symbol propagation The existing code was sufficient to pass through and relocate most debug symbols as necessary. It was just disabled for some reason. The only bugs were in the handling of non-text line numbers, which aren't ever used as far as I can tell, and include files, which should be relocated like line numbers to match ALN's behavior.
Convert output symbol table back to a table It looks like at some point the output symbol was converted from an actual table of SYMREC structs to an in-memory copy of a COFF/a.out symbol table. This entailed relying on the assumption that all symbols had an entry in the string table when using OSTLookup()'s return value as anything other than a boolean value, as is done in the relocation procesing logic. In preparation for adding support for debug symbols, which often have no string table entry, revert to using an intermediate output symbol table representation and serializing it one symbol at a time when writing the output file. This simplifies various code paths, but potentially slows down writing COFF symbol tables to disk. Fortunately, this table is not written with default options, and is rather small unless using debug symbols, so this shouldn't significantly affect the runtime of most existing use cases.
Add Alcyon C object file support Support ingesting the DRI Alcyon C object file format in addition to a.out object files. The load file routine simply translates the Alcyon object file into an a.out file before passing it on to the existing processing workflow. The motivation here was to enable linking of the binary-only cinepak decompression GPU routines provided in the developer files. ALN can handle these files just fine, and now RLN can too. However, that is a very simple object files To fully exercise the relocation table translation code, contrived assembly files with all types of relocations were assembled as Alcyon C object files using MADMAC and BSD/a.out object files using RMAC (Note RMAC had to be used to generate the a.out files because MADMAC generates invalid a.out relocations for certain relocation types that it handles fine in Alcyon format), and then both object files were linked as COFF executables using RLN. The resulting COFF files were verified to be identical.
Handle absolute BSS segment location of 'xt' When linking an absolute executable, the data segment and BSS segment can be assigned an absolute address, or the special value 'x' to indicate they are contiguous with the prior segment (text for data, data for BSS). However, RLN (like MAC) also accepts an optional segment specifier after the special value 'x' that allows explicitly specifying which segment the current one is contiguous with. For data, the only valid value is 'xt', meaning contiguous with text. However, when the data segment is specified to be at an explicit address rather than contiguous with the text segment, it is valid to specify that the BSS segment is contiguous with data ('xd') or with text ('xt'). RLN was accepting these additional 't' and 'd' values, but ignoring them. This change causes RLN to correctly place the BSS segment after the text segment when its location is specified as 'xt' as long as the data segment isn't also contiguous with the text segment.
Added fixups for OP data addresses. This is the counterpart to the RMAC Object Processor assembler. In order for it to be useful, we need to be able to address things in the OP sections that refer to 68xxx TEXT and DATA sections--so now that's possible with a little tweak to the section relocator. Now at version 1.6.1 (we forgot to commit 1.6.0, sorry!).