04 November 2021, 02:23 | #1 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
GCC 3.2.3 and binutils 2.14a
Hi.
Because of work done on the mainframe, I have spent a lot of effort making GCC 3.2.3 a C90-compliant application, e.g. it doesn't call fork(). Because of work done on PDOS/386, I have also made binutils 2.14a C90-compliant. But in both cases, this C90-compliant source code that should work out of the box with any C compiler only supports the targets I have hand-crafted and created a makefile for. I have my own "make" program too - pdmake, which doesn't require tabs. I would now like to get both of these custom distributions to support targeting 68000 Amiga hunks. Ideally I'd like it to use the Motorola syntax for assembly. From searching on the web, it seems that the Amiga hunk format was never officially supported for binutils but there was unofficial support for it and/or a tool to convert from ELF to Amigahunk. Ideally if someone has spent the effort to properly support Amigahunk, I would like that incorporated into my product, to help preserve the technology. I'll need something that doesn't violate the GPL license that these products are copyrighted under. Could someone please provide direction within the above constraints? Thanks. |
04 November 2021, 02:42 | #2 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
https://github.com/bebbo/binutils-gdb is the binutils for Bebbo's GCC 6.5 cross compiler.
|
04 November 2021, 06:06 | #3 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
/* BFD back-end for Commodore-Amiga AmigaOS binaries. Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. Contributed by Leonard Norrgard. Partially based on the bout and ieee BFD backends and Markus Wild's tool hunk2gcc. Revised and updated by Stephan Thesing. So hopefully that doesn't have post-2.14a features and still works in 2.14a and I can figure out how to incorporate it. |
|
04 November 2021, 06:08 | #4 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
You're welcome!
|
04 November 2021, 23:35 | #5 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
I guess there's a fundamental problem here that the owners of GCC/binutils mainstream don't say "oh wow, you support the Amiga - that's fantastic!" and work to incorporate that into the mainstream. Similarly, they actually said out loud that they were "keen to delete" the i370 mainframe target which I was working on.
One thing I noticed with my C library, which supported MVS, was that suddenly I had someone contact me with code changes for CMS. I think I will make my distributions a repository for "retro" computing. |
05 November 2021, 00:12 | #6 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Actually it's more than just retro. The problem is that the build system relies on you being able to run some shell, which may not exist. For people who just have a C compiler, such as SAS/C, I am expecting a simple makefile that builds a simple set of C files. Which is in fact what I have been creating in my distributions. So the Amiga will just be part of that.
|
05 November 2021, 04:15 | #7 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
I tried changing the code I had, but ran into a problem with amigaoslink.c where I'm unsure what changes to make. It's certainly non-trivial. binutils 2.14 is dated 2003 and binutils 2.14a is dated 2011, so there should have been an 8-year period when every GCC distribution used this. Anyone have a link to the Amiga code for this time period? It'd be terrible if this stuff was lost. I actually chose 2.14a because it was before they deleted a target I was interested in (i386-aout) and should have been compatible with GCC 3.2.3 which was released in 2003, and had years of stability. I'm not after the latest greatest features, I'm after stability because I'm trying to make a viable product instead of replacing one set of bugs that are not affecting me with a set of bugs that may affect me. I've already fixed two bugs in 2.14a that affected Windows PE and i386-aout. Here are the old binutils: https://ftp.gnu.org/gnu/binutils/ |
|
05 November 2021, 08:32 | #8 |
Registered User
Join Date: Jan 2005
Location: UmeƄ
Age: 43
Posts: 922
|
Might the source for binutils from the Fred Fish ADE/GG help? It is an older version of the bfd/amigaos.c and I think ADE/GG is where the amiga-gcc stuff came from, but please correct me if I am wrong.
http://aminet.net/package/dev/gg/binutils-src |
05 November 2021, 11:33 | #9 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Full compatibility doesn't work. AFAIK, later gcc versions can emit most instructions and adressing modes following the Motorola syntax (except for differences like "mov", "movm" or "jra"), but the assembler directives will stay the same.
Quote:
Quote:
|
||
05 November 2021, 22:47 | #10 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
|
|
05 November 2021, 23:03 | #11 | |||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
https://sourceforge.net/p/pdos/gitco...b/amistart.asm Quote:
Quote:
|
|||
05 November 2021, 23:58 | #12 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
https://github.com/bebbo/amigaos-binutils-2.14 I've verified the code seems to be inbetween the other 2 releases, and now I'm trying to beat it into shape. |
|
06 November 2021, 02:31 | #13 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
My assembler code has these errors though: F:\devel\pdos\pdpclib>\devel\binutils-2.14a\as-pdos amistart.asm amistart.asm: Assembler messages: amistart.asm:24: Error: Unknown operator -- statement `section "CODE",code' ignored amistart.asm:25: Error: Unknown operator -- statement `xref ___start' ignored amistart.asm:51: Error: Unknown operator -- statement `section "BSS",bss' ignored I commented those lines out and it compiled without error and produced this, which looks like Amiga format: F:\devel\pdos\pdpclib>hexdump a.out 000000 000003E7 00000002 612E6F75 74000000 ........a.out... 000010 000003E8 00000002 2E746578 74000000 .........text... 000020 000003E9 0000000A 23CF0000 00222F07 ........#...."/. 000030 2F082F00 4EB90000 00004FEF 000C4E75 /./.N.....O...Nu 000040 202F0004 2E7A0004 4E750000 00000000 /...z..Nu...... 000050 000003EC 00000001 00000000 00000002 ................ 000060 00000000 000003EF 81000002 5F5F5F73 ............___s 000070 74617274 00000001 0000000E 01000003 tart............ 000080 5F5F5F61 6D697374 61727400 00000000 ___amistart..... 000090 01000002 5F5F5F65 78697461 00000018 ....___exita.... 0000A0 00000000 000003F2 ........ Where do I stand now? I'd like to support both vasm and gas/as. Should I be using conditional compilation to support both formats? Or should I change my code to be gnu format (not sure what it requires yet) and then use a parameter to vasm to accept that format? Another thing is that I will need to use "ar" and I don't think "ar" supports Amiga format. I need to use a.out instead I think for object code, to produce a .a and then "ld" can produce an Amiga hunk. I'm going to work on gcc 3.2.3 now. |
|
06 November 2021, 04:57 | #14 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
More good news! I was able to get gcc 3.2.3 to target 68020 (I think). What this means is that we now have a C90-compliant compiler, meaning it can run in hostile (non-POSIX) environments like PDOS-generic (under Amiga OS).
I'm not sure whether the calling convention is correct though. It's generating this code: int foo(int a, int b) { return (a+b); } #NO_APP .text .even .globl _foo _foo: link a6,#0 movel a6@(8),d0 addl a6@(12),d0 unlk a6 rts and it needs to be compatible with this code: ___amistart: move.l sp,savedSP * Don't use movem to push the arguments because the order * is not what you code yourself, but other rules. move.l d7,-(sp) move.l a0,-(sp) move.l d0,-(sp) jsr ___start lea 12(sp),sp rts although I guess I can always just change the startup code. But it also needs to work with this code: Read: MOVEM.L D2/D3/A6,-(A7) MOVEA.L _DOSBase,A6 MOVEM.L 16(A7),D1/D2/D3 JSR -042(A6) MOVEM.L (A7)+,D2/D3/A6 RTS So that will potentially need to change too. Or I can potentially modify GCC 3.2.3 if someone can spot something wrong with the GCC-generated code. Note that the GCC-generated code is able to be assembled with the binutils "as" I previously created. I'm now going to get "ar" and "ld" to build. Note that my binutils is also C90-compliant. |
06 November 2021, 09:00 | #15 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
"ld" is taking a long time to crack.
Even though I have the binutils 2.14 source, as usual, the GNU people don't provide C90 code that compiles on any compiler. You instead need to be able to support bash or similar. It so happens I have Cygwin installed, but it still breaks. The older version breaks too. So working source code remains elusive. However, with a separate configure in the "ld" directory I was able to get "ld" built. Using this configure command: ./configure --target=m68k-unknown-aout --with-sysroot --disable-nls --disable-werror on the Amiga 2.14 source code I downloaded, I get this, which looks wrong: ld-new: supported targets: a.out-zero-big cisco-ios-core-big ieee srec symbolsrec tekhex binary ihex ld-new: supported emulations: m68kaout It looks like it is building 64-bit a.out instead of 32-bit Amiga hunks. Does anyone know the principles at play here? What are we expecting to see from "ld"? When I do my own build I get this: ld-pdos: can't set BFD default target to `m68k-unknown-aout': Invalid bfd target |
07 November 2021, 01:21 | #16 | |||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
sectiondirectives everything is written into the .textsection. Not necessarily what you want. Quote:
Unlike GNU-as, vasm supports multiple syntax styles. So you could write your assembler sources in GNU-as syntax and compile vasm with make CPU=m68k SYNTAX=std. Quote:
Quote:
That's the infamous MIT syntax for m68k. Probably no other m68k assembler, other than GNU-as, supports it. |
|||||
07 November 2021, 07:06 | #17 | |||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Good news. I have managed to build ld and ar. "ld" was a can of worms. The fundamental problem was that I didn't know you needed to configure with m68k-amigaos and because of the mention of a.out I thought that the a.out target had been modified to build the Amiga, so I had configured with m68k-aout and when I tried to reconfigure with different options, I didn't realize that they weren't taking effect in the subdirectories. A clean configure does in fact build usable code. I have now merged both bebbo's 2.14 mods and mine. Another problem was that the Amiga target was using the non-C90 function "fstat" which I only had a stub for, and when I realized that that might be the cause of the mostly-empty executables, I reworked the binutils code to stop using fstat.
The end result is at http://pdos.org/custom.zip (that's both binutils 2.14a and gcc 3.2.3) So this is useful if you only have a C90 environment. I'll distribute Windows executables as part of the PDOS/386 distribution in due course. Quote:
Quote:
Quote:
Anyway, that means my GCC 3.2.3 based system can now build Windows, MVS and Amiga executables so that I can do a better job of triangulating and abstracting. |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
gcc .lib | mritter0 | Coders. C/C++ | 13 | 27 October 2018 02:13 |
gcc and cybergraphics | zeGouky | Coders. C/C++ | 3 | 20 November 2016 04:08 |
GCC problems | Minuous | Coders. C/C++ | 3 | 08 September 2016 16:16 |
gcc linker | mritter0 | Coders. C/C++ | 3 | 21 December 2014 16:54 |
StormC4/GCC | JoJo | Coders. General | 0 | 28 October 2002 09:38 |
|
|