GNAT backend generates incorrect code for return from __gnat_malloc.

[Stephen N Chivers]

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]

Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Michael Schmitz]

Hi Geert,


I'd like to have a more streamlined way of syncing Geert's patch queue - can
git or rsync be used for that, Geert?


You can rsync from e.g.
rsync://rsync.kernel.org/pub/linux/kernel/people/geert/linux-m68k-patches-2.6


Thanks, that worked like a charm (other than your include move patche breaking 
because elf.h got changed).



However, I'd really like to switch to git, like most other maintainers.
Then I can have separate for-linus, linux-next, and m68k-v2.6.27
branches.


Good plan ...


However, those (master, for-linus, linux-next) will have to be rebased
frequently, so plain `git pull' (without `-f') won't work for all of
you.


I'd just pull m68k :-)

Michael


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Michael Schmitz]

Hi Frank,


Can you checksum that file on another computer, to check if the CD is
OK? If there is md5sum in the install ramdisk, you may be able to
checksum it from the installer itself as well.


Checked it. The checksum is fine.


I had another go with the dayli etch ISO as of Thursday, the kernel boots fine 
and I got to set console keymaps and the ethernec module OK. Without the 
etch-m68k hacks, I got as far as picking a mirror (which had no m68k etch, of 
course).


With the etch hacks, I got a hang while detecting the CD-ROM.

I'll give it another try, but first I have to play with 2.6.27 ...

Michael


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]