GCC 6.2 toolchain for AmigaOS 3

I'm curious. Will it be possibly to run the compiler etc on the Amiga itself if I were to try and compile it.
You see, I'd prefer to do my program building on the Amiga too.

[_dante_]

I have a problem using the toolchain on macOS Sierra 10.12.6.

First, I tried to use the precompiled, hosted build available at https://franke.ms/download/amiga-gcc-macos.tgz

Everything seemed to work until I wanted to compile sample program with libnix using -noixemul switch which results in the following error:

$ m68k-amigaos-gcc hello.c -noixemul -o hello
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/lib/libstubs.a(__UtilityBase.o):__UtilityBase.o:(.data+0x4): undefined reference to `__utilityname'
collect2: error: ld returned 1 exit status

Searching libstubs.a for '__utilityname'

m68k-amigaos-nm /opt/amiga/m68k-amigaos/lib/libstubs.a | less

I found only

__UtilityBase.o:
00000000 D ___LIB_LIST__
00000000 D ___UtilityBase
         U ___utilityname

without the

...
utility.o:
00000000 D ___utilityname
...

I found in the thread that it could be related to corrupted libnix build (but it's sad if the hosted version also suffer from that) thus I decided to compile the toolchain from sources.

I installed required packages using 'brew' including bash and gawk (as it was suggested in the thread to better use gnu awk than apple's awk because the second one is producing wrong header files) - in fact I tried both scenarios with gawk and apple's awk with no success.

Having all set up I did the steps according the instruction:

git clone https://github.com/bebbo/amiga-gcc
cd amiga-gcc
make update SHELL=/usr/local/bin/bash
make clean SHELL=/usr/local/bin/bash
make clean-prefix SHELL=/usr/local/bin/bash
make all SHELL=/usr/local/bin/bash

It goes well until it is building libnix, where the compilation is terminated with the following errors (full build log in the attachments):

m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 -S /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/__oslibversion.c -o extra/__oslibversion.S 2>&1|tee extra/__oslibversion.err
m68k-amigaos-gcc -E -traditional -D_DOSBase=___DOSBase -D_UtilityBase=___UtilityBase -D_MathIeeeSingBasBase=___MathIeeeSingBasBase -D_MathIeeeSingTransBase=___MathIeeeSingTransBase -D_MathIeeeDoubBasBase=___MathIeeeDoubBasBase -D_MathIeeeDoubTransBase=___MathIeeeDoubTransBase -D_LocaleBase=___LocaleBase extra/__oslibversion.S -o extra/__oslibversion__2.S
m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 extra/__oslibversion__2.S -c -o extra/__oslibversion.o
rm extra/__oslibversion.S extra/__oslibversion__2.S
if test ! -s extra/__oslibversion.err; then rm extra/__oslibversion.err; fi
m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 -S /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c -o extra/allocvec.S 2>&1|tee extra/allocvec.err
In file included from /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h:16:0,
                 from /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:2:
/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:6:8: error: expected identifier or '(' before '{' token
 void * AllocVec(unsigned size, unsigned flags) {
        ^
/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:13:6: error: expected identifier or '(' before '{' token
 void FreeVec(unsigned * ptr) {
      ^
m68k-amigaos-gcc -E -traditional -D_DOSBase=___DOSBase -D_UtilityBase=___UtilityBase -D_MathIeeeSingBasBase=___MathIeeeSingBasBase -D_MathIeeeSingTransBase=___MathIeeeSingTransBase -D_MathIeeeDoubBasBase=___MathIeeeDoubBasBase -D_MathIeeeDoubTransBase=___MathIeeeDoubTransBase -D_LocaleBase=___LocaleBase extra/allocvec.S -o extra/allocvec__2.S
m68k-amigaos-gcc: error: extra/allocvec.S: No such file or directory
m68k-amigaos-gcc: fatal error: no input files
compilation terminated.

As I have written, I tried different scenarios using default apple's awk or gnu's awk. Tried also building with explicitly set clang compiler

CC=clang CXX=clang++ make all SHELL=/usr/local/bin/bash

All these efforts without success.

What I have missed or what I'm doing wrong?

Any help highly appreciated...
Thanks!

[Hedeon]

Normally, utilityname = utility.library. Not sure why it is not defined.

And nix13 is for AOS1.3 i think. I believe the file will add a custom AllocVec/FreeVec as those do not exist in 1.3. Maybe you are using 3.x includes to compile 1.3 stuff?

Just guessing here.

[Samurai_Crow]

Utility.library was introduced in Kickstart 2. It should not be defined in 1.3.

[_dante_]

Regarding 'utilityname' during sample code compilation:

Based on crt libraries supported I assume that compiling sample program for AOS1.3 requires additional switch -mcrt=nix13 to use libnix comapatible with AOS1.3.

I never used that switch (only -noixemul), so I think the default libnix is nix20 which should have __utilityname defined.

Regarding building libnix itself during toolchain compilation:
My basic understanding of the toolchain makefile is that ndk13 is 'emulated' based on ndk39. So it shouldn't be an issue building nix13/extra/allocvec.c containing emulated AllocVec/FreeVec routines which are based on ndk39 declarations that are included from /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h. But the problem I can think of is that /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h contains only preprocessor #defines and not declarations for AllocVec/FreeVec so their definition in the nix13/extra/allocvec.c is somehow incorrect to the compiler.

I wonder if it is related only to the toolchain compilation under macOS or Windows guys have similar issues?

[alkis]

Originally Posted by _dante_

$ m68k-amigaos-gcc hello.c -noixemul -o hello
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/lib/libstubs.a(__UtilityBase.o):__UtilityBase.o:(.data+0x4): undefined reference to `__utilityname'
collect2: error: ld returned 1 exit status

Can you provide a small source code (hello.c?) that illustrates the problem? We can then try to compile it and see if that's something in your end or in the toolchain.

[_dante_]

Sure!

Source of hello.c is in fact Bebbo's 'simple C file to test' from https://franke.ms/amiga/gcc.wiki and it contains the following code:

#include <stdio.h>

int main(int argc, char **argv) {
        puts("hello world!");
        printf("argc=%ld\r\n", argc);
        for (int i = 0; i < argc; ++i) {
                printf("arg=%s\r\n", argv[i]);
        }
        return 0;
}

[alkis]

There is something wrong at your end.

m68k-amigaos-gcc hello.c -noixemul -o hello
alex[0]@omen eab$ ls -ltr hello
-rwxrwxr-x 1 alex alex 10568 ???  18 22:41 hello

Everything compiles fine here, on linux host.

[Leffmann]

Originally Posted by _dante_

I wonder if it is related only to the toolchain compilation under macOS or Windows guys have similar issues?

I can't build the toolchain for macOS, but on Windows Subsystem for Linux Ubuntu both the toolchain and that test program builds fine.

[bebbo]

Originally Posted by _dante_

I have a problem using the toolchain on macOS Sierra 10.12.6.

First, I tried to use the precompiled, hosted build available at https://franke.ms/download/amiga-gcc-macos.tgz

...

I uploaded a recent version.

Also building the toolchain on that crappy wanker operating system is working again.

[_dante_]

Hi Bebbo!

The toolchain builds fine now under macOS but still only the 'newlib' crt is usable

It means that only build using the command below results in properly built executable:

m68k-amigaos-gcc hello.c -o hello-newlib

Building with 'libnix' crt still doesn't work at all, but the error is different as now it doesn't even progress to the linking phase:

m68k-amigaos-gcc hello.c -noixemul -o hello-noixemul

... or equivalent command (if I understood correctly)...

m68k-amigaos-gcc hello.c -mcrt=nix20 -o hello-nix20

... or AOS 1.3 compatible ...

m68k-amigaos-gcc hello.c -mcrt=nix13 -o hello-nix13

results in compilation errors related to unknown type name '__FILE':

In file included from /opt/amiga/m68k-amigaos/sys-include/stdio.h:60:0,
                 from hello.c:1:
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:304:3: error: unknown type name '__FILE'
   __FILE *_iobs;
   ^~~~~~
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:390:3: error: unknown type name '__FILE'
   __FILE *_stdin, *_stdout, *_stderr; /* XXX */
   ^~~~~~
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:425:3: error: unknown type name '__FILE'
   __FILE *__sf;           /* file descriptors */
   ^~~~~~
In file included from hello.c:1:0:
/opt/amiga/m68k-amigaos/sys-include/stdio.h:66:9: error: unknown type name '__FILE'
 typedef __FILE FILE;
         ^~~~~~
In file included from hello.c:1:0:
/opt/amiga/m68k-amigaos/sys-include/stdio.h: In function '__sputc_r':
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:10: error: request for member '_w' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
          ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:26: error: request for member '_w' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
                          ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:36: error: request for member '_lbfsize' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
                                    ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:693:14: error: request for member '_p' in something not a structure or union
   return (*_p->_p++ = _c);
              ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h: In function '_getchar_unlocked':
/opt/amiga/m68k-amigaos/sys-include/stdio.h:747:10: error: request for member '_r' in something not a structure or union
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));
          ^
/opt/amiga/m68k-amigaos/sys-include/stdio.h:747:10: error: request for member '_p' in something not a structure or union
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));
          ^

Building with 'clib2' crt also fails but this time during the linking stage:

$ m68k-amigaos-gcc hello.c -mcrt=clib2 -o hello-clib2
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: cannot find ncrt0.o: No such file or directory
collect2: error: ld returned 1 exit status

I don't know if it could help somehow but I did manage to achieve the same results (with the same compilation errors) using previous toolchain code (without yours today's commits) when I excluded building of nix13 directory in "projects/libnix/sources/Makefile.in" or when I commented out the #include <inline/exec.h> in "projects/libnix/sources/nix13/extra/allocvec.c". I see that your solution for the 'libnix' compilation problem is by undefining AllocVec and FreeVec macros as they were caused errors during compilation of "projects/libnix/sources/nix13/extra/allocvec.c". It's of course better solution but similar result with errors mentioned above. I wonder though why compiling on Ubuntu doesn't produce the same errors - why GCC doesn't see these macros defined?

In the meantime I tried to build hello.c with all these crts under Ubuntu and it works great in each case.

Your support is invaluable so I would really appreciate 'libnix' and 'clib2' crts usable with your toolchain also on macOS

[bebbo]

Originally Posted by _dante_

Hi Bebbo!

The toolchain builds fine now under macOS but still only the 'newlib' crt is usable

**removed some lines **

In the meantime I tried to build hello.c with all these crts under Ubuntu and it works great in each case.

Your support is invaluable so I would really appreciate 'libnix' and 'clib2' crts usable with your toolchain also on macOS

It comes down that

  readlink("/proc/self/exe", buf, 1023);

does not yield the executable path. And thus computing the libnix include folders failes. This might also affect other include path calculations and causes that ndk13-includes are not resolved too - that's why the macros for AllocVec/FreeVec are picked up...

I tried different approaches to get the executable path including
_NSGetExecutablePath,
proc_pidpath, ...
and nothing seems to work. (Maybe this increases your tolerance of my judgement for this os).

And no - I do not rollback to the static compiled prefix path.^

EDITH: I got _NSGetExecutablePath working.

but building libnix:

awk: ... makes too many open files

OMGWTF

I finally updated https://franke.ms/download/amiga-gcc-macos.tgz

[cdh]

Thank you Bebbo such an incredible cross-compiling toolchain! Your work is helping to enable a new generation of code for our classic Amiga computers.

Using your compiler, I've started porting an app (current OpenSSH) to the 68k Amiga which requires TCP sockets. I'm having some minor difficulty that probably someone more familiar with the 68k ABI and assembly can help with.

My development environment is Fedora 28, with The Bebbo gcc version I pulled and built from git:

    gcc version 6.4.1b 20181213-223951 (GCC)

My test environment is currently FS-UAE 2.9.7DEV5 with the UAE bsdsocket.library.
I'm compiling with flags

-Os -mcrt=clib2 -m68020-60 -lnet

among others.

The high level symptom I'm having is that a call to accept() on an established socket fails with a return code of -1, but errno = 0. This occurs just as the remote host attempts a connect. The remote host remains connected (to FS-UAE) even though the accept() returns -1.

I've investigated on the FS-UAE code and as far as I can tell, it is correctly inserting an fd number in register d0 before returning.

The relevant code in

projects/clib2/library/socket_accept.c

is as follows:

        new_socket_fd = __accept(socket_fd,cliaddr,(LONG *)addrlen);
        PROFILE_ON();

        if(new_socket_fd < 0)
        {
                SHOWMSG("could not accept connection");
                goto out;
        }

Using gdb to disassemble the above, I see:

   0x0007b4cc <+20>:    movea.l 0x18fc <main+1104>,a6
   0x0007b4d2 <+26>:    movea.l d0,a0
   0x0007b4d4 <+28>:    move.l 16(a0),d0
   0x0007b4d8 <+32>:    movea.l 20(sp),a0
   0x0007b4dc <+36>:    movea.l 24(sp),a1
   0x0007b4e0 <+40>:    jsr -48(a6)
   0x0007b4e4 <+44>:    blt.s 0x7b534 <accept+124>
   0x0007b4e6 <+46>:    jsr 0x85610 <__find_vacant_fd_entry>

Here's where I'm a little beyond my depth. To me, the above looks to be in error because it's not doing a

tst.l d0

before the

blt.s

instruction.

If I make a minor addition to the accept() library code:

        new_socket_fd = __accept(socket_fd,cliaddr,(LONG *)addrlen);
        PROFILE_ON();
        __asm("");

        if(new_socket_fd < 0)
        {
                SHOWMSG("could not accept connection");
                goto out;
        }

then the accept() call works as expected, and returns a valid fd to my calling program. Disassembly of accept() looks "better" to my untrained eyes as well:

   0x0007b4cc <+20>:	movea.l 0x18fc <main+1104>,a6
   0x0007b4d2 <+26>:	movea.l d0,a0
   0x0007b4d4 <+28>:	move.l 16(a0),d0
   0x0007b4d8 <+32>:	movea.l 20(sp),a0
   0x0007b4dc <+36>:	movea.l 24(sp),a1
   0x0007b4e0 <+40>:	jsr -48(a6)
   0x0007b4e4 <+44>:	move.l d0,d3
   0x0007b4e6 <+46>:	tst.l d0
   0x0007b4e8 <+48>:	blt.s 0x7b538 <accept+128>
   0x0007b4ea <+50>:	jsr 0x85634 <__find_vacant_fd_entry>

Where the compiler now saves d0 in d3 (??), and then does the

tst

that I would have expected.

Is there something wrong with the inline assembler of __accept()?

#define __accept(sock, addr, addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  LONG * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (__SocketBase);\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register LONG * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen)  \
  : "d1", "a0", "a1", "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})

It looks okay to me, though I'm certainly not an expert.

I obviously have a work-around for this specific problem, so there is no immediate need for a solution. The concern I have is that I might run into a similar problem in other bsdsocket.library interface functions as I get more of this code port functional.

[bebbo]

it seems tha some macros do work and some don't.

The amiga-gcc provides ndk-include/inline/bsdsocket.h with

#define accept(sock, addr, addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  socklen_t * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (BSDSOCKET_BASE_NAME); register int _d1 __asm("d1"); register int _a0 __asm("a0"); register int _a1 __asm("a1");\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register socklen_t * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r" (_d1), "=r" (_a0), "=r" (_a1),  "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen) \
  : "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})

so regarding this example code:

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>

#include <netdb.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
 
 
#include <inline/bsdsocket.h>
extern struct Library * SocketBase;

#if defined(C)
#define __SocketBase SocketBase
#define __accept(sock,addr,addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  LONG * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (__SocketBase);\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register LONG * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen)  \
  : "d1", "a0", "a1", "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})
#define foo __accept
#else
#define foo accept
#endif



int
myaccept(int sockfd,struct sockaddr *cliaddr,socklen_t *addrlen)
{
	int new_socket_fd = foo(sockfd, cliaddr, (LONG *)addrlen);

        if(new_socket_fd < 0)
        {
                puts("could not accept connection");
        }
	return new_socket_fd;
}

the result of

 m68k-amigaos-gcc -Os sock.c -S -o ndk.s

and

 m68k-amigaos-gcc -Os sock.c -S -o clib.s -DC

differs:

diff ndk.s clib.s
20d19
<       move.l d0,d2

so one of the macros triggers a bug - why?.

The difference is here:

ndk:

	jsr a6@(-48:W)
				|	0	  !*d0 !+d1                               !*a0 !*a1                  a5 !.a6   a7     !*f0 !*f1

vs

clib2

	jsr a6@(-48:W)
				|	20	  !*d0 !*d1                               !*a0 !*a1                  a5 !.a6   a7     !*f0 !*f1

with the ndk macro register d1 is marked as modified.
with the clib2 macro register d1 is marked as read and modified.

and this difference triggers a bug where my optimizer does not check for asm stuff and throws the superfluous assignment to d0 away :-)

guess I have to fix it...

[bebbo]

ok, the fix is life.

And I still consider the ndk macro as more precise.

[cdh]

Originally Posted by bebbo

ok, the fix is live.

And I still consider the ndk macro as more precise.

Thank you. I appreciate the quick fix and will be happy to test it once it lands -- I assume in one of the following repos:
https://github.com/bebbo/amiga-gcc

https://github.com/bebbo/gcc

https://github.com/bebbo/binutils-gdb

[_dante_]

Originally Posted by bebbo

EDITH: I got _NSGetExecutablePath working.

but building libnix:

awk: ... makes too many open files

I pulled recent sources and on my mac the whole toolchain builds fine under the clang compiler from the latest Xcode.

Regarding the "awk: ... makes too many open files" - maybe usage of 'gawk' installed using 'brew' is getting rid of these errors, as I have it installed to override Apple's awk and I didn't get that error while building libnix.

More than that, using the toolchain compiled myself, I was able to compile 'hello' program with all available crt libs (newlib, clib2, libnix13 and libnix20) - so in terms of macOS support the toolchain seems to work now perfectly as expected!

Thanks Bebbo

[arti]

I've took precompiled clib2 libraries from mac toolchain but all libs give error :
"Could not read symbols: File in wrong format." when linking.

My compiler is gcc 3.4.6.

Any idea why?

[Samurai_Crow]

Bebbo's GCC uses HUNK format like SAS/C and every other AmigaOS compiler. Earlier GCC versions used ELF formatted object code.

[bebbo]

Originally Posted by arti

I've took precompiled clib2 libraries from mac toolchain but all libs give error :
"Could not read symbols: File in wrong format." when linking.

My compiler is gcc 3.4.6.

Any idea why?

your toolchain does not support the amiga hunk format.