https://lwn.net/SubscriberLink/888741/ff866473b15a8a6d/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account A way out for a.out [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! By Jonathan Corbet March 24, 2022 The a.out executable format dates back to the earliest days of Linux -- and before. It has not been used in any serious way for decades, but support still exists in the Linux kernel and has resisted all attempts at its removal. Back in January, Borislav Petkov tried yet again to delete support for this format, leading to another extended discussion. There is one difference this time around, though: the effort to get rid of a.out support might just succeed. The a.out format dates back to the first edition of Unix. When MINIX came along, it naturally used that format for its executable files; that, in turn, led to a.out being used in Linux as well. It is a simple format, and its implementation on Linux was even simpler; among other things, every Linux shared library had to be centrally assigned its own portion of the address space, since libraries could not be relocated at run time. Still, Linux used a.out for some time, until support for the newfangled ELF format was first added to the 0.99.13 development kernel in 1993. There was a time when the crazier people among us manually converted our Slackware systems from a.out to ELF in order to be able to try it out and gain the benefits before distributions were updated. They still bear the scars from that time. Not that your editor would ever admit to knowing anybody who would have engaged in any such activity. ELF has been the standard executable format for Linux on most architectures since 1995. One might think that would have provided enough time for any users of a.out binaries to grudgingly move on to ELF; its adoption can probably be judged to not be a passing fad at this point. But, in the real world, surprises lurk. The initial conversation on removing a.out faded out fairly quickly, but was restarted when Eric Biederman posted a patch disabling the building of a.out support on the two architectures (Alpha and m68k) that still enable it by default. This patch did not actually remove the support, it just turned it off to see if anybody would scream. If protests were raised, support could be turned back on quickly and easily; otherwise a full removal could be done. Linus Torvalds quickly responded that he was "pretty sure we can't do this". He pointed out that the native executable format on Alpha systems running Digital's Unix was essentially a.out, even if it went by the newer name of ECOFF. The Linux a.out loader can run ECOFF programs by virtue of ignoring some of the newer ECOFF features; taking it out would break any systems still using that support. One might think that the number of users who are still using Alpha CPUs, running ECOFF binaries on those CPUs, and tracking current kernel releases might be a fairly small number, but one never knows. Kees Cook did do a little research on, seemingly, the only distribution that still supports Alpha (Gentoo) and found that the only ECOFF files present contained firmware, which does not run on the CPU anyway. He concluded that there would be no harm from removing a.out support on this platform: "Let's do it". It seems to be a universal rule that somebody always has to come along to ruin the party. In this case, just as it seemed like there were no further obstacles to the removal of a.out, James Jones showed up to let it be known that he was still using a.out: The use case is running an old set of tools to build programs for the Atari Jaguar. Namely, Atari's assembler (mac) and linker (aln). The alternative is running windows versions in dosbox, or using some replacements that have been developed based on an even older, less-featureful version of the source code for mac and aln, but which still haven't managed to add back in all the features needed to build some programs or use the Atari debugging tools (Also available in a.out only). He gave some more details on why he still needed to use these tools in this followup message Moving a program to a new executable format is normally just a matter of rebuilding the program. But rebuilding is a rather more difficult task in the absence of the source code. Finding oneself stuck trying to run a decades-old binary on modern systems is just one of the many joys reserved for users of proprietary software -- but many people have found themselves in that position at one time or another. They are legitimate Linux users, and there is no desire to break their systems. So Petkov duly gave up and asked only that Jones document his usage of a.out for the benefit of those who might try to remove it in the future. Cook, however, was not so quick to throw in the towel; he looked at the programs in question and concluded that it might be possible to write an ELF wrapper program that could load and run old a.out binaries. One day later, he posted such a program, noting that it could run the aln program at least far enough for it to complain about its command-line arguments. Jones tried it out and was pleased with the results: Yes, works perfectly, thank you. I like the idea of using this much better than getting emailed every time someone wants to delete the a.out code again. Consider my use case withdrawn. I've already pushed an update to my jaguar-sdk project to use this tool instead. So removal of a.out support is back in the plans for the 5.18 kernel. Perhaps the effort will succeed this time, though there are still no guarantees; there may be a.out users who are unaware of the coming apocalypse and haven't yet made their objections known. If those users are unable or unwilling to use Cook's wrapper utility, the excision of a.out support may, once again, have to be deferred to some future kernel release. Index entries for this article Kernel a.out [Send a free link] ----------------------------------------- (Log in to post comments) A way out for a.out Posted Mar 24, 2022 15:50 UTC (Thu) by dullfire (subscriber, #111432) [Link] If cook didn't take this approach: then making the wrapper be a binfmt_misc tool (and having a libre license) would probably be the most forward compatible. After all there's no reason an interpreter (ld.so) couldn't parse all the a.out binaries and libs in question, and then relocate itself out of the way before constructing the final run-time image. Or, if the programs properties were just right, you could get even fancier and convert the program to elf (of course you could not take advantage of elf features) in memory, before actually "exec-ing" it. [Reply to this comment] A way out for a.out Posted Mar 24, 2022 16:09 UTC (Thu) by wtarreau (subscriber, #51152) [Link] And I thought I was using old stuff... $ cat /proc/version Linux version 2.4.37-wt1-utm10.1-alix (willy@wtap) (gcc version 3.3.6) #1 Tue Dec 9 12:50:07 CET 2008 Waiting for this PC-Engines ALIX to die but it doesn't want to. It has only known ELF anyway, I migrated to ELF with kernel 2.0 (except for floppy disks for which I kept the smaller a.out a bit longer). Jonathan, like you I was one of those installing libc.so.4 and libc.so.5 side by side on Slackware to try to figure if ELF would bring anything (by then it only brought slightly slower program execution IMHO but it was the future). Not everything worked out of the box, but overall it used to be much more seamless than the following migration to glibc2 where the low-level network API completely changed and required many network programs to be heavily modified! [Reply to this comment] A way out for a.out Posted Mar 24, 2022 16:38 UTC (Thu) by corbet (editor, #1) [Link] And here I'd thought I had successfully suppressed the painful memories from the glibc2 transition...thanks a lot, man...:) [Reply to this comment] A way out for a.out Posted Mar 24, 2022 16:43 UTC (Thu) by smoogen (subscriber, #97) [ Link] Oh no.. you already triggered flashbacks for many of us. You get to watch us crawl around with our terror weighted blankets for a week or so. Then someone will go over the changeover from libc5 to libc6, and we can start all over again. [Reply to this comment] A way out for a.out Posted Mar 24, 2022 18:33 UTC (Thu) by hrw (subscriber, #44826) [Link ] Nice! Alix was fun platform. That Geode LX cpu which was either 586 or 686 depending who asked. Always can run newer stuff but having system running so old software i would keep it alive until death (their or mine). [Reply to this comment] A way out for a.out Posted Mar 24, 2022 22:51 UTC (Thu) by nix (subscriber, #2304) [Link] My Soekris net5501 firewall is still running. Geode LX, again :) (I really must replace it one of these days: having a single point of failure that is 13 years old is worrisome. I have a Turris Omnia I keep meaning to set up, but the new system is so crazy weird I haven't dared to try to actually replace it yet. It's a shame nobody makes anything like the net5501 with lots and lots of network ports any more :( I need at least five...) [Reply to this comment] A way out for a.out Posted Mar 24, 2022 17:05 UTC (Thu) by glaubitz (subscriber, #96452) [Link] Quote: "Kees Cook did do a little research on, seemingly, the only distribution that still supports Alpha (Gentoo)" That is not correct though. Debian is also still supporting the Alpha architecture among other older architectures under the umbrella of the Debian Ports project. See: https://cdimage.debian.org/cdimage/ports/ and: https:// www.ports.debian.org/ Disclaimer: I'm one of the primary maintainers of Debian Ports. [Reply to this comment] A way out for a.out Posted Mar 24, 2022 17:20 UTC (Thu) by pebolle (subscriber, #35204) [ Link] > an ELF wrapper program that could load and run old a.out binaries Nitpick: that's not a wrapper but a loader, isn't it? Anyhow, would it be possible to write an a.out to ELF converter? Ie, a program that is fed an a.out executable and creates an ELF executable (basically this loader and the a.out dumped into an ELF executable). [Reply to this comment] A way out for a.out Posted Mar 24, 2022 20:21 UTC (Thu) by gutschke (subscriber, #27910) [Link] A.out is an insanely simple file format, and basic ELF isn't really all that complex either. So, I would expect that there'd be some way to convert a.out to ELF without too much effort. In particular, it appears as if the only binaries anybody cares about are statically linked already. That should dramatically simply things. I haven't looked too closely. But there might be some need to add a bit of assembly "glue". Shouldn't be much, but that would be architecture-specific. Maybe, that's why a wrapper turned out to be easier to code. The only other remaining issue is the fact that a.out wants to be loaded to an address that is very low. In fact, it's so low that it is usually not allowed to be mapped from user space. So, you'd quite possibly end up with ELF binaries that fail to start until you reconfigure your system, and you won't get any informative error messages. The wrapper addresses that problem a little nicer and prompts you what to do. If I think hard enough, I can imagine solutions for all these problems. But they get increasingly more complex, for something that really doesn't justify this amount of engineering effort. If the wrapper works, that's likely the most expedient and pragmatic solution. [Reply to this comment] A way out for a.out Posted Mar 24, 2022 17:51 UTC (Thu) by halla (subscriber, #14185) [ Link] "There was a time when the crazier people among us manually converted our Slackware systems from a.out to ELF in order to be able to try it out and gain the benefits before distributions were updated." I remember trying that... [Reply to this comment] A way out for a.out Posted Mar 24, 2022 20:29 UTC (Thu) by cuviper (subscriber, #56273) [ Link] Now, will GCC ever change the default executable name from "a.out"? [Reply to this comment] A way out for a.out Posted Mar 24, 2022 21:49 UTC (Thu) by JoeBuck (subscriber, #2330) [ Link] a.out goes back to the original Unix, and apparently came from "assembler output", even though it is really linker output. So the name is at least 40 years old. Changing it at this point is probably not worth the bother, since there's probably something that depends on that. [Reply to this comment] A way out for a.out Posted Mar 24, 2022 22:36 UTC (Thu) by gerdesj (subscriber, #5446) [ Link] "Changing it at this point is probably not worth the bother, since there's probably something that depends on that." A shitload of documentation. lol here's some C, wack it into a file called x.c, run this (gcc command) and then run ./a.out. [Reply to this comment] Copyright (c) 2022, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds