I am trying to compile software with t-rexky's gcc 3.4.6 on a Previous instance running OpenSTEP 4.2 patch 4.
This is the compiler:
bash-3.2$ gcc -v
Reading specs from /usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/specs
Configured with: /LocalDeveloper/PortsSVN/gcc-3.4.6~ns/configure --prefix=/usr/local --enable-languages=c,c++ --disable-shared --disable-threads --disable-multilib
Thread model: single
gcc version 3.4.6 (t-rexky NEXTSTEP build 1)
Machine information:
bash-3.2$ hostinfo
Mach kernel version:
NeXT Mach 4.2: Tue Jan 26 11:23:59 PST 1999; root(rcbuilder):Objects/mk-183.34.4.obj~2/RELEASE_M68K
Kernel configured for a single processor only.
1 processor is physically available.
Processor type: MC680x0 (68040)
Processor speed: 33 MHz
Processor active: 0
System type: 5
Board revision: 0xf
Primary memory available: 128.00 megabytes.
Default processor set: 47 tasks, 83 threads, 1 processors
Load average: 0.20, Mach factor: 0.79
Here's the code. It is so simple, that it really should not fail.
bash-3.2$ cat test.c
int main(void)
{
return 0;
}
bash-3.2$ gcc test.c -o test
bash-3.2$ ./test
Bus error
bash-3.2$ gcc test.c -S -fverbose-asm -o test.s
bash-3.2$ cat test.s
;# GNU C version 3.4.6 (t-rexky NEXTSTEP build 1) (m68k-next-nextstep3)
;# compiled by GNU C version 3.4.6 (t-rexky NEXTSTEP build 1).
;# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
;# options passed: -D_NEXT_SOURCE -auxbase-strip -fverbose-asm
;# options enabled: -feliminate-unused-debug-types -fpeephole
;# -ffunction-cse -fkeep-static-consts -freg-struct-return -fgcse-lm
;# -fgcse-sm -fgcse-las -fsched-interblock -fsched-spec
;# -fsched-stalled-insns -fsched-stalled-insns-dep -fbranch-count-reg
;# -fcommon -fverbose-asm -fargument-alias -fzero-initialized-in-bss
;# -fident -fmath-errno -ftrapping-math -m68020 -mc68020 -mbitfield -m68881
;# -m68020-40 -m68332 -mcpu32
;# -mshared-library-id=_current_shared_library_a5_offset_
.text
.align 1
.globl _main
_main:
pea a6@
movel sp,a6
clrl d0 ;# <result>
unlk a6
rts
The system cc produces similar code, the resulting binary does not crash:
cat test2.s
.text
.align 1
.globl _main
_main:
pea a6@
movel sp,a6
clrl d0
jra L1
L1:
unlk a6
rts
I somehow suspect that it is not the additional (useless?) jra instruction that makes this work, but there doesn't seem to be any objdump available for this system
Any ideas?
I'm surprised the jump makes a difference. I wonder what would happen if you assembled both .s files by both compilers (making four binaries in total) --- would some binaries work and others not work? In other words, maybe the problem lies downstream of where you're looking...
I've been getting pukes like this, too. I ended up going back to the NeXT compiler, assuming it was just me, but now that there's someone to corroborate it... well, that's reassuring!
Might try to test it on NS3.3 to see if it works there.
@Rhetorica I have not tried NeXTstep 3.3 but I would be interested to hear your experience there if you have a NeXTstep 3.3 installation ready.
@stepleton You anticipated the direction this is going into...
GCC will do this:
gcc -v -pipe test.c -o gtest
Reading specs from /usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/specs
Configured with: /LocalDeveloper/PortsSVN/gcc-3.4.6~ns/configure --prefix=/usr/local --enable-languages=c,c++ --disable-shared --disable-threads --disable-multilib
Thread model: single
gcc version 3.4.6 (t-rexky NEXTSTEP build 1)
/usr/local/libexec/gcc/m68k-next-nextstep3/3.4.6/cc1 -quiet -v -D_NEXT_SOURCE test.c -quiet -dumpbase test.c -auxbase test -version -o - |
as -o /usr/tmp/ccX0ZkLW.o
ignoring nonexistent directory "/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/include/c99"
ignoring nonexistent directory "/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/../../../../m68k-next-nextstep3/include"
ignoring nonexistent directory "/NextDeveloper/Headers/c99"
ignoring nonexistent directory "/LocalDeveloper/Headers/ansi"
ignoring nonexistent directory "/LocalDeveloper/Headers/bsd"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/include
/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/include/ansi
/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/include/bsd
/NextDeveloper/Headers
/NextDeveloper/Headers/ansi
/NextDeveloper/Headers/bsd
/LocalDeveloper/Headers
End of search list.
GNU C version 3.4.6 (t-rexky NEXTSTEP build 1) (m68k-next-nextstep3)
compiled by GNU C version 3.4.6 (t-rexky NEXTSTEP build 1).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/usr/local/libexec/gcc/m68k-next-nextstep3/3.4.6/collect2 -o gtest -lcrt0.o -lcrtbegin.o -L/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6 -L/usr/local/lib/gcc/m68k-next-nextstep3/3.4.6/../../.. /usr/tmp/ccX0ZkLW.o -lgcc -lsys_s -lgcc -lcrtend.o
whereas the builtin cc will do
cc -v -pipe test.c -o test
Reading specs from /lib/m68k/specs
NeXT Software, Inc. version cc-744.13, gcc version 2.7.2.1
/lib/m68k/cpp-precomp -smart -lang-c -v -arch m68k -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -D__GNU__ -Dmc68000 -Dm68k -DNeXT -Dunix -D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k" -D__mc68000__ -D__m68k__ -D__NeXT__ -D__unix__ -D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k" -D__mc68000 -D__m68k -D__NeXT -D__unix -D__STDC__ -D_NEXT_SOURCE -DNX_COMPILER_RELEASE_3_0=300 -DNX_COMPILER_RELEASE_3_1=310 -DNX_COMPILER_RELEASE_3_2=320 -DNX_COMPILER_RELEASE_3_3=330 -DNX_CURRENT_COMPILER_RELEASE=410 -DNS_TARGET=41 -DNS_TARGET_MAJOR=4 -DNS_TARGET_MINOR=1 -D__NEXT_CPP__ -D__DYNAMIC__ test.c |
/lib/m68k/cc1obj -arch m68k -quiet -dumpbase test.c -version -dynamic -fPIC -o - |
/lib/m68k/as -arch m68k -o /usr/tmp/cc000540-test.o
NeXT DevKit-based CPP 4.0
GNU Obj-C version 2.7.2.1 (68k, MIT syntax) compiled by GNU C version 2.7.2.1.
/bin/ld -arch m68k -o test -dynamic -lcrt1.o /usr/tmp/cc000540-test.o -lcc_dynamic -framework System
/bin/objcunique test
And if I compile test.c to test.o and link it the way cc does, the binary will indeed not crash with a bus error. Analogous, if I link the cc generated .o file with the gcc linker call it will die with a bus error.
@t-rexky Are you still reading this forum? Do you have any suggestions?
I have it working under NS3.3 in Previous. Getting the headers fix (
https://www.nextcomputers.org/NeXTfiles/Software/New_Ports/NS33HeadersFix-1.2.s.tar.gz) to install took slightly more work than I expected (it wouldn't install over NFS from my Windows host machine).
Note that I did have to pass a magic ranlib wand over some random .a file before things worked.
I have a suspicion that when I tried to install the OpenStep version of the headers fix (
https://www.nextcomputers.org/NeXTfiles/Software/New_Ports/OS42HeadersFix-1.0.NIHS.s.tar.gz), I didn't actually get it to install, and this is the source of my (our?) problems. Trying that next.
UPDATE: OS42HeadersFix did originally leave a .pkg in my /NextLibrary/Receipts; I'm reinstalling it to see if that helps.
UPDATE 2: No dice.
Wasted some time today trying to compile GCC 3.4.6 under i386 OS4.2. Unfortunately I have no idea where to start after my initial compile attempt failed; the log only appears to show an endless stream of
warnings before barfing.
It's unfortunate t-rexky didn't leave us his source or patches. rjbrown99 did leave us (
https://github.com/rjbrown99/next) a gcc 2.95 patch set for NS3.3 m68k though, so I might try compiling that on both platforms...
My patches should still work, originally tested on black hardware. I was more recently trying to get my Intel VM updated but haven't gone past gcc 2.95 yet.
Happy to take feedback or collaborate. My latest idea was to see if an older apt/dpkg could be ported. We really need a solid package manager for open source. Would make it a lot easier to get a reasonable system that somewhat resembles a more modern day cli experience.
Out of interest, how long does it take to compile this gcc version on a NeXT box/Previous ?
Quote from: rjbrown99 on July 13, 2024, 10:05:11 PMHappy to take feedback or collaborate. My latest idea was to see if an older apt/dpkg could be ported. We really need a solid package manager for open source. Would make it a lot easier to get a reasonable system that somewhat resembles a more modern day cli experience.
Good to see you're still around and kicking!
I started out a few weeks ago with a naive dream of trying to port pkgsrc from NetBSD, on the premise that it would be closer to the shared BSD ancestry than something removed like apt. Unfortunately I have next to no knowledge of the culture or lore of POSIX development, so I came up against obstacles at pretty much every turn, but I think if we can get it bootstrapped going (what with its proven track record of portability, and all), then we'll probably get a lot of packages for free.
Quote from: pTeK on July 13, 2024, 10:58:34 PMOut of interest, how long does it take to compile this gcc version on a NeXT box/Previous ?
I assume you meant 3.4.6, rather than 2.95.3? Haven't tried either yet—but definitely ages. Simply failing at getting 3.4.6 to build on Intel took hours under VMware.
I'm about to start a 2.95.3 attempt now using rjbrown99's/Savarese's patches.
Quote from: Rhetorica on July 14, 2024, 02:39:15 AMgeez, i'm really posting too much
Glad I'm not the only one. ;D
Quote from: Rhetorica on July 14, 2024, 02:38:18 AMI assume you meant 3.4.6, rather than 2.95.3? Haven't tried either yet—but definitely ages. Simply failing at getting 3.4.6 to build on Intel took hours under VMware.
Wow a couple of hours compile time . Crazy :o would be faster on intel compared to 68k
I am still around. I was no longer getting pinged by the forum so I was only receiving notifications when logging in. I think I fixed that now.
Just a very quick few points:
- My source code changes are in gcc-3.4.6~ns1.diff file that is included in gcc-3.4.6~ns1.Ns.tar.gz. There are also some additional notes in the README file.
- I do not recall if I ever tested the compiler binaries running on OS, but I would not be surprised to see some problems.
- I have not done much on the NeXT in the past few years, but my gcc-3.4.6 has been the standard compiler that I have been using since the original port and I have not seen any issues whatsoever when running on NS3.3.
- A lot of my historical efforts have been summarized in the respective threads on here. This whole exercise was a proof of concept. I am not sure how much actual benefit is there to running 3.4.6 vs the stock compiler. The idea at the time was to explore the potential for bootstrapping a much more modern set of NS system libraries to allow smoother porting of more recent software. I was able to complete the required framework, including the ability to create new shared libraries.
- Bootstrapping the complete setup from scratch was a Sisyphean effort and included back-and-forth between various machines. Particularly "back porting" the OS X cctools-435.4~ns2 onto NS involved addressing numerous circular-reference pre-requisites. Don't ask me exactly how I managed, but the binaries I supplied work very well on NS and can be used as a starting point for any future work.
- I even managed (again as proof of concept) to successfully cross compile m68k NS3.3 binaries on my G5 PowerMac, at "blinding" speed. But I stopped short of cross-linking the object files - I linked them on the NeXT and the executables worked fine.
- Coding is only a hobby for me, so consider all this whole exercise a huge "hack" rather than a well-planned exercise. I am an aerospace engineer by trade.
Cheers.
Quote from: stefan on July 07, 2024, 11:47:33 PMI somehow suspect that it is not the additional (useless?) jra instruction that makes this work, but there doesn't seem to be any objdump available for this system
Today I learned that
otool -t -v <file> disassembles. Add
-V to see label names.
EDIT: After having argued with BinaryNinja and Ghidra for a while, I would recommend otool to anyone, as the labels produced with -V include system and runtime symbols that won't be visible to an external decompiler. In the case of HyperSense, I found it yielded both the names of C runtime essentials like strcpy and sprintf, and NeXT-specific ObjC names like NXToAscii and NXWriteObjectReference.
The new(?) oldcomputers-archive.fr dump of the PEAK NeXTStep Archive includes two versions (
http://www.oldcomputers-archive.fr/NeXT/openstep/mach/apps/devtools/) of gcc for OPENSTEP 4.x, identified as 2.7.2.3.3 and 2.8.1.2. AFAIK these are the newest binaries that will work under OS4.2. Anyone wanna give 'em a shot?