Re: [Ada] multilib patch take two => multilib build working

[Paolo Bonzini <bonzini at gnu dot org>]

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.

> > > guerby@gcc17:~/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