I have done some work towards establishing a GNAT cross compilation
environment for
my configuration of x86 host and MVME167 target. The '167 is running a
sarge based
configuration as a diskless computer.
The version of gcc employed is gcc-4.1.2 fetched from ftp.gnu.org. I have
used the native
include files and libraries from the '167 installation on the cross
compilation host.
The GNAT/gcc backend is generating incorrect code for the return value from
__gnat_malloc.
The symptoms are that any program generated by the ADA compilation process
dies during
elaboration of the ADA package system.secondary_stack with a segmentation
violation
(SIGSEGV).
The cause is the __gnat_malloc function, in ADA package system.memory,
returns the allocated
memory address in data register d0 whereas the compiler is generating code
that expects the
result to be in address register a0.
For 'compiler' generated calls to __gnat_malloc, i.e. those generated
whenever the ADA new statement
is compiled, the return value is specified by init_gigi_decls in
gcc/ada/utils.c.
In this file the statement setting up the __gnat_malloc return value reads:
malloc_decl = create_subprog_decl (get_identifier ("__gnat_malloc"),
NULL_TREE,
build_function_type (ptr_void_type_node,
tree_cons
(NULL_TREE,
sizetype,,
endlink)),
NULL_TREE, false, true, true, NULL,
Empty);
it is the ptr_void_type_node that seems to be the problem.
I have trialled a fixed version of utils.c that replaces the
ptr_void_type_node with integer_type_node. This
certainly causes the compiler to generate code that correctly retrieves the
return value from register.
d0. This is based on limited testing and does not involve ADA programs with
tasks as tasking support
for the 68k is not enabled in the standard gcc 4.1.2 compiler.
I think the point here is that GNAT for the 68k normally generates code for
address returns
in register a0. The 68k architecture being one of the few that
distinguishes between address and
data registers.
I am not certain what the full effect of making this change is and am
uncertain what the effect
would be for other architectures and operating systems.
There is a hint that others associated with the Debian Project have done
work on GNAT for the 68k
but the results are not that evident.
Stephen Chivers,
CSC Australia Pty. Ltd.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
