Subject: port-x68k/3123: GCC fails to take 68060 cache effects into account.
To: None <gnats-bugs@gnats.netbsd.org>
From: Robert Dick <dickrp@dickrp.remote.princeton.edu>
List: netbsd-bugs
Date: 01/17/1997 17:37:04
>Number:         3123
>Category:       port-x68k
>Synopsis:       GCC fails to take 68060 cache effects into account.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 17 14:50:01 1997
>Last-Modified:
>Originator:     Robert Dick
>Organization:
	
>Release:        1.2
>Environment:
Amiga 3000, Cyberstorm MK-II 68060-50Mhz, NetBSD-1.2
>Description:
I have known about this first problem for a while and I reported it to
the FSF months ago.  Although it may be FSF's problem, I though NetBSD folks
would be interested as GCC is our native compiler.

GCC 2.7.2 (and 2.7.2.1) makes assumptions about the
cache on a m68k which are incorrect for the 68060.  This results in
incorrect behavior when nested functions are used.  I ran into this under
ADE's AmigaOS gcc port and had hoped that things were better in NetBSD but
the GCC that comes with 1.2 exhibits this problem, too.  I tried compiling
the ``current'' GCC at ftp.warped.com but it isn't currently in a buildable
state.  It isn't likely that this problem was fixed, though, because I
looked the related trampoline code and it looks the same as in the vanilla
2.7.0 distribution.

This nested function test from the GStep distribution code executes
correctly when single-stepped through using GDB.  It also runs correctly
under AmigaOS when I disable CPU caches.

If it is run normally, it results in a segmentation violation or a
completely hung machine. As a consequence, it is not possible to use the
GStep Objective-C class library or nested functions on a 68060.

As a side note.  I have found a (very long and resistant to simplification)
program which does not make use of trampolines
and behave incorrectly on a 68060 when caches are enabled but correctly
on other architectures or on a 68060 when single-stepped using GDB.  GCC
just can't deal with a 68060 properly yet.

>How-To-Repeat:
Execute the nested function test from the GStep distribution:
  int main() {
    int a = 2; void nested(int b) { a += b; }
    void doit(void(*f)(int)) { (*f)(4); } doit(nested);
    if (a != 6) exit(-1); exit(0);
  }
>Fix:
Provide proper trampoline cache clearing macros in config/m68k/m68k.h.
With a write-back cache enabled, the variables wedged on the stack are not
written (data) before they are interpreted as code and used to jump to
other locations.  This will make more sense when the assembly in m68k.h
is inspected.  I a bit afriad of the code in here because the
comments are sparse and wrong; they contradict the code.
Also, I have tried to locate the initial research paper describing trampoline
implementation in GCC but it isn't at the FTP site noted in the GCC manual,
it's not at the new FTP site the old one points me to.  The person who
wrote the paper doesn't reply to my email, and I haven't found anyone with
a copy of the paper.

There are other problems with GCC and the 68060 that I have no idea how to
locate, let alone fix.
>Audit-Trail:
>Unformatted:
Submitter-Id:	net
>System: NetBSD entropy 1.2 NetBSD 1.2 (ENTROPY) #13: Thu Dec 5 01:32:53 EST 1996 root@entropy:/home/src/sys/arch/amiga/compile/ENTROPY amiga