Removers Library - a.out Binary Emulation Dropped From Linux Kernel

[+cubanismo]

3 hours ago, Zerosquare said:

Isn't it possible to convert a binary from a.out format to something more modern like ELF?

(Honest question -- I've not looked into it.)

I messed around with this last year, trying to use objcopy to extract the sections one by one and then recombine them into an ELF file. IIRC, I got an ELF version of MAC that would launch to its input prompt if given no parameters but crash as soon as it tried to do anything, and a non-functioning ALN. If anyone's interested in carrying on that work, I can probably dig up the script I used. It seems like it should work in theory if someone fiddled with it enough, but it could be that the resulting binary would also rely on some other crusty thing that Linux only sets up when the process is an a.out binary. Note both MAC and ALN are entirely statically linked, including the standard C library. If this weren't the case, it would probably be impossible to get this working.

[42bs]

10 hours ago, cubanismo said:

trouble. I have all my other files and stuff on my regular machine. If I have to boot a VM and copy it all over there

I use VirtualBox for various VMs and have my development folders mounted in them. No need to copy anything in or out of the VM.

I guess it is less trouble to set this up then trying to convert an a.out to an ELF file.

 

[ggn]

From my perspective, I think Jaguar binaries are relatively easy: Just follow the path of least resistance. Use whatever modern tools there are.

• gcc with elf support? Who cares, just use ld to link the binary at an absolute address. $4000 for a nice .bjl file, $802000 for a .rom file. Convert .bjl to .abs/.cof if you like. Or, for .rom, slap a header at the front and pad the file to the nearest 1,2,4,6,8mb. Done.
• rmac won't assemble the 30 year old source code? Just convert the source code to assemble. Compare the output to a "reference" one created with older tools, verify it's the same, done. Move on.
• Want to use more fancy c/c++ lib features that require initialisers to be called? We've made that on on ST which is even more difficult (as we have to create relocatable program files and we had to create an .elf->ST .prg converter, for more information read here, here for more info, and check out the repositories here and here).

Using the above philosophy I was able to compile some C code for the Jaguar using gcc 11.2.0 (with elf support) and rmac and create a working rom in less than one day (and that took so long because I needed to write some startup and utility code).

 

If I had to set up VMs and try to get musty compilers running, I'd probably have given up before I started. But nope, all tools run natively on Windows and a full rebuild of the codebase (which is a few thousand lines of C and asm code and includes building a ROM file) takes about 1 second.

 

Bonus content: the command line to link the object files into a .bjl file:

 

    +' <list of .o and .lib files> -o build/image.bin'
    +' -m68000'
    +' -Wl,--oformat,binary,-Ttext=4000,-e,start'
    +' $CODEGEN_FLAGS$'
#if PRODUCE_MAP_FILE
    +' -Wl,-Map,build_waaar/adam.map'
#endif
    +' -nostdlib -nostartfiles'
#if LTO
    + ' -flto'
#endif

 

[+cubanismo]

Agreed, all valid points. Perhaps it's just the preservationist in me, but I do like having mac and aln available right there on my regular systems.

 

For those that didn't follow the related LKML traffic, the developers were willing to let me patch the a.out support back in (quite gracious of them IMHO), but the end result is that Kees Cook threw together a very basic userspace a.out loader program that is good enough to execute the mac and aln binaries on a kernel that only supports ELF binaries, available here:

 

https://github.com/kees/kernel-tools/tree/trunk/a.out

 

It'll only work on very simplistic a.out binaries, but it should cover all the Jaguar tools (I don't have an Alpine board, so I can't really test rdbjag and wdb, but I tried to test mac and aln pretty thoroughly). I've updated my SDK with a simple wrapper script to re-route the a.out binaries through this tool as of this commit:

 

https://github.com/cubanismo/jaguar-sdk/commit/22abac7e0b0e83871e413c328d43ec4fc577036c

[+BitJag]

@cubanismo I was watching the email thread and it great to see discussion that led to a solution for running these old binaries.  Thanks for putting in the work!