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

[laurent at guerby dot net]

Selon Arnaud Charlet <charlet@adacore.com>:

> >> 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.

They can still read the wrong system.ads in case of multiple rts installed, the
only way to be sure is to use gcc -c -gnatdg with your flags on your source :).

> Also, this points to a real flaw in the approach, since e.g. in case
> of little/big endian multilibs, similar issue would arise.
>
> And, system.ads is only the tip of the iceberg: if you do not get system.ads
> right, it means that potentially a complete wrong set of sources will be
> used to build the run-time, since there can be an arbitrary number of
> target dependent units as defined by LIBGNAT_PAIRS, and indeed, looking
> at the target pairs for x86 and x86-64, these are quite different, so we
> need to find a mechanism to properly select the right pair when using
> multilib.

This will need some additionals tests on MULTILIB in the LIBGNAT_TARGET_PAIRS
machinery (3 files for x86 vs x86_64, solaris looks like already done, powerpc
seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like a
blocking issue with the proposed design since each MULTILIB rts build has
completely separate directory and stamp (through RTSDIR) so there is no
possibility of conflict through sharing.

Do you agree with this assessment? If so I'll propose an update patch.

Thanks in advance,

Laurent