Arnaud Charlet wrote:
I had to solve one rts source issue though:
gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of
bits for a word (64 and 32 respectively), I changed them both to be
completely the same and use GNAT defined Standard'Word_Size attribute.
- Word_Size : constant := 64;
- Memory_Size : constant := 2 ** 64;
+ Word_Size : constant := Standard'Word_Size;
+ Memory_Size : constant := 2 ** Word_Size;
The same change will have to be done on other 32/64 bits Ada targets. I
don't know if this change has adverse effect on GNAT build in some
situations.
I think this is worthwhile on its own, before the build patch goes in.
Not clear to me actually. The idea currently is to make these values
explicit so that when people read system.ads, they know right away what
the right value is.
Also, this points to a real flaw in the approach, since e.g. in case
of little/big endian multilibs, similar issue would arise.
Yes, if different multilibs should use different sets of sources, we
have a problem.
On the other hand, this is also something that can be solved by moving
the RTS to libada. The standard approach with C multilibs is to rely on
configure tests, or on #define constants, to pick the appropriate choice
between multilibs, and I don't see why this shouldn't work with Ada.
For example, g-soccon* files are generated automatically -- then, why
not go one step further and generate a g-soccon file at configure time?
It seems that a branch would be more appropriate for this kind of work,
since there's a long way to go before getting in reasonable shape.
Given the above, I agree.
Also, it's not clear how using $(RTS) for building gnattools will work
properly.
Only target modules are multilibbed, so only one copy of gnattools is
built. I assume that the characteristics of the target do not affect
the operation of gnattools -- different multilibs may use different
filesystem paths and thus behave differently, but the *code* of
gnattools should be the same in all cases.
[EMAIL PROTECTED]:~/tmp$ gnatmake -f -g
-aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p
There's an existing mechanism in gnatmake which is the use of the --RTS switch,
so ideally it would be great to match multilib install into --RTS=xxx
compatible dirs, and also have -xxx (e.g. -32 or -64) imply --RTS=xxx.
Yes, you would basically take from gcc.c the code that turns "-m32" into
"use multilib 32", and use it to make a --RTS option.
Paolo
