Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
02-03-2014, 03:17 AM
|
#1
|
Member
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo~amd64, CentOS-7, Slackware64-current, FreeBSD-11.1, Arch
Posts: 229
Rep: 
|
Running old a.out binaries on Slackware64-current
More out of curiosity than any compelling need, I wanted to relive the good old days of 1993 again with any early Slackware (a typical RCS revision is @(#)/etc/rc.d/rc.inet1 1.01 05/27/93). I rebuilt the kernel modules using the default generic configuration for kernel 3.10.17 adding only the ia32_aout to those already configured. The module then cleanly loaded with modprobe.setarch i386 --uname-2.6 -3 -R -X -Z -F -L -B ./tetris
Then I replicated the libc4-era ancient libraries (libc.so.4.4.2 and others of that vintage) to /lib. There were no name conflicts between those libraries and the modern ones.
But upon trying to run any of the binaries, here's what happens and it's what occurs with any of the old commands -- not just tetris:
Code:
strace -f ./tetris
execve("./tetris", ["./tetris"], [/* 52 vars */]) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
Prefixing it with setarch i386 does not improve matters nor with any combination that it affords such as setarch i386 --uname-2.6 -3 -R -X -Z -F -L -B ./tetris.
I've read that Alan Cox has been able to run old a.out binaries on modern Linux. Has anyone tried this form of time travel with success? The strace doesn't give a lot to go on. This happens on both bare metal and three virtual machines (VirtualBox, VMPlayer and QEMU).
Last edited by re_nelson; 02-03-2014 at 03:19 AM.
|
|
|
02-03-2014, 09:15 PM
|
#2
|
Member
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo~amd64, CentOS-7, Slackware64-current, FreeBSD-11.1, Arch
Posts: 229
Original Poster
Rep: 
|
Quote:
Originally Posted by re_nelson
More out of curiosity than any compelling need, I wanted to relive the good old days of 1993 again with any early Slackware (a typical RCS revision is @(#)/etc/rc.d/rc.inet1 1.01 05/27/93). I rebuilt the kernel modules using the default generic configuration for kernel 3.10.17 adding only the ia32_aout to those already configured.
|
For anyone else pining "...for the days when men were men and wrote their own device drivers...", here's how I have successfully been able to time travel to 20+ years ago on my shiny, new Slackware64-current system.
1). Build the modules using Pat's stock 3.10.17 configuration with this option enabled: CONFIG_IA32_AOUT=m.
2). Alter the command line flags to add this parameter: noexec=off. This is the key and provided the solution to my problem.
3). Arrange for modprobe ia32_aout to execute at boot time via /etc/rc.d/rc.local.
Then party like it's 1993!
Code:
chroot /var/historic/slackware.historic/ /bin/env -i USER=root HOME=/ TERM=linux PS1='\u:\w\$ ' SHELL=/bin/bash PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/bash -login
Linux 0.99pl13. (Posix).
No mail.
root:/# uname -rv
3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013
root:/# cat > a.c
int main(void) {
puts("Greetings from the 20th century and the world of a.out.");
return 0;
}gcc -v a.c
Reading specs from /usr/lib/gcc-lib/i486-linux/2.4.5/specs
gcc version 2.4.5
/usr/lib/gcc-lib/i486-linux/2.4.5/cpp -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386 -Dlinux -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -D__i486__ a.c /usr/tmp/cca01426.i
GNU CPP version 2.4.5 (80386, BSD syntax)
/usr/lib/gcc-lib/i486-linux/2.4.5/cc1 /usr/tmp/cca01426.i -quiet -dumpbase a.c -version -o /usr/tmp/cca01426.s
GNU C version 2.4.5 (80386, BSD syntax) compiled by GNU C version 2.4.5.
as -o /usr/tmp/cca014261.o /usr/tmp/cca01426.s
ld -dll-verbose -m486 /usr/lib/crt0.o -L/usr/lib/gcc-lib/i486-linux/2.4.5 /usr/tmp/cca014261.o -lgcc -lc -lgcc
Fixup count 0
Removed 1174 symbols from symtab
Fixup table address: 1064
root:/# ./a.out
Greetings from the 20th century and the world of a.out.
root:/# file a.out && ldd a.out
a.out: Linux/i386 demand paged executable not stripped
libc.so.4 (DLL Jump 4.4pl1)
root:/# gawk -W version
Gnu Awk (gawk) 2.13, patchlevel 2
root:/# gawk -F: '$3 > 404' /etc/passwd
gonzo::418:1::/home/gonzo:/bin/bash
satan::419:1::/home/hell:/bin/bash
snake::420:1::/home/pit:/bin/bash
A survey a few months back placed a lot of Slackers in my generation (AARP and beyond) so I figured some would get a kick out of such antiquity. "But if memories were all I sang / I'd rather drive a truck". Now that the problem has been solved, I'm heading back to the future and will launch a command that wasn't even a pipedream way back then: slackpkg update. Just thinking about the jump tables of that era got me cured real quick of my flirtation with the not-so-good olde daze.
|
|
3 members found this post helpful.
|
02-03-2014, 09:35 PM
|
#3
|
Member
Registered: Oct 2011
Distribution: Slackware64
Posts: 364
Rep:
|
Cool. Good post. I might give this a go, next snowbound weekend. It would cool to see what it was like even before my first install of 3.3.
|
|
|
02-07-2014, 04:20 PM
|
#4
|
Member
Registered: Nov 2005
Location: Serbia
Distribution: Slackware
Posts: 231
Rep: 
|
Thanx. I have to try this when I catch more time for playing with retro stuff.  Anyway, I think the problem is not limited only to Slack64 Current. I remember having problems with 32-bit 14.0 and probably 13.37. Couldn't find a solution on the web at the time.
|
|
|
02-07-2014, 04:31 PM
|
#5
|
Member
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo~amd64, CentOS-7, Slackware64-current, FreeBSD-11.1, Arch
Posts: 229
Original Poster
Rep: 
|
Quote:
Originally Posted by bobzilla
Thanx. I have to try this when I catch more time for playing with retro stuff.  Anyway, I think the problem is not limited only to Slack64 Current. I remember having problems with 32-bit 14.0 and probably 13.37. Couldn't find a solution on the web at the time.
|
You're right. Indeed its transcends any particular Linux operating system, Slackware or otherwise. The noexec=off kernel command line allows the ancient a.out binaries to run any number of both 64 and 32-bit platforms I have handy here, Arch, Gentoo-2.2 AMD64 and my own system, loosely based on Linux from Scratch.
For some additional background, my interest in going retro was triggered by going down memory lane by trying to build Emacs-19.34b on all of the above (and more) systems. The dump process of creating emacs from temacs would invariably segfault. That ultimately led to gaining real knowledge of ASLR (Address space layout randomization), something that was only vague to me at the time. Both the noexec=off kernel flag and the twiddling of the --addr-no-randomize flag with setarch are relevant. The latter allowed me to build that old Emacs set the course for me learn more about means to defeat the feature of address randomization. There's also a personality(2) flag that can set to enable a process to bypass address space randomization.
By the way, it's not prudent to disable the noexec flag on a production system. It's there for a reason. I only toggle it when I want to enter a time tunnel back to the early 1990s.
Last edited by re_nelson; 02-07-2014 at 04:42 PM.
|
|
|
02-07-2014, 04:50 PM
|
#6
|
Member
Registered: Nov 2005
Location: Serbia
Distribution: Slackware
Posts: 231
Rep: 
|
Quote:
Originally Posted by re_nelson
By the way, it's not prudent to disable the noexec flag on a production system. It's there for a reason. I only toggle it when I want to enter a time tunnel back to the early 1990s.
|
Of course. But I guess you wouldn't run 1994 a.out binary on a production system either. 
|
|
|
All times are GMT -5. The time now is 01:17 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|