[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

["mikpe at it dot uu.se" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835

--- Comment #8 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-11 12:33:09 UTC ---
Created attachment 24491
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24491
patch fixing m68k function call abi issues in gnat

WRT the the m68k function call ABI issues, I believe there are only a few cases
where gnat does something which breaks m68k:

- __gnat_malloc is defined in Ada to return Address (integer, so in d0), but
it's called from a couple of places via fake "extern" declarations that pretend
it returns void* (pointer, so in a0).  The attached patch fixes the two call
sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well
as the internal fake prototype (init_gigi_decls).
- Source code inspection showed that get_jmpbuf_address probably suffers from
the same issue (mismatching decl and use via wrong intermediate fake prototype)
so I fixed that too.

There are a number of pointer-returning C library routines that are imported
as-is with fake prototypes that declare them as returning Address.  While
wrong, this should work since the ABI returns pointers in both d0 and a0.

With these fixes in place I can bootstrap gnat et al and the resulting binaries
can be executed:

aranym5_21_~/gnatroot/bin/gnat
GNAT 4.4.7 20110419 (prerelease)
Copyright 1996-2008, Free Software Foundation, Inc.

List of available commands

gnat bind               gnatbind
gnat chop               gnatchop
gnat clean              gnatclean
gnat compile            gnatmake -f -u -c
gnat check              gnatcheck
gnat sync               gnatsync
gnat elim               gnatelim
gnat find               gnatfind
gnat krunch             gnatkr
gnat link               gnatlink
gnat list               gnatls
gnat make               gnatmake
gnat metric             gnatmetric
gnat name               gnatname
gnat preprocess         gnatprep
gnat pretty             gnatpp
gnat stack              gnatstack
gnat stub               gnatstub
gnat xref               gnatxref

Commands find, list, metric, pretty, stack, stub and xref accept project file
switches -vPx, -Pprj and -Xnam=val

However, compiling the most trivial Ada program now fails with an assertion:

aranym5_22_cat conftest.adb 
procedure conftest is begin null; end conftest;
aranym5_23_~/gnatroot/bin/gcc -S conftest.adb
+===========================GNAT BUG DETECTED==============================+
| 4.4.7 20110419 (prerelease) (m68k-unknown-linux-gnu) Assert_Failure
einfo.adb:1748|
| Error detected at system.ads:153:5                                       |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

conftest.adb

compilation abandoned

In case I missed some return value ABI fixups I hacked the m68k backend to
return pointers in a0+d0 as before but always fetch them from d0, but it made
no difference.

The only potential issues I'm aware of now are endianess and alignment
differences between the bootstrap host (i686-linux in my case) and m68k. 
That's because the bootstrap has to run the host's gnatmake a couple of times
to generate the einfo/sinfo/etc thingys, which might not work correctly if the
host and target have different endianess or alignment rules.

Since I've bootstrapped gnat for big-endian ARM from little-endian i686 before,
I don't think endianess is the problem, so I'm leaning towards m68k's unique
alignment rules.