This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Ada] multilib patch take two => multilib build working
Paolo Bonzini wrote:
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.
Unless you want to have a combination of switching
system* or generating them, I don't know how you will
get this. Certainly a general mechanism for inserting a
few values like endian, word size, etc would cover many
of the variations but you might still have odd variations
that require switching the files.
When dealing with multilibs, I don't know that it is
really possible to assume that you can look at a file
and directly know what the "truth" is for a particular set of
CPU options. In many cases, you have CPU CFLAGS that
use CPU model names and then map onto an arbitrary
directory which corresponds to the ISA used. For example,
for a SPARC/ERC32 you use -mcpu=cypress and that maps
onto a V7 set of libraries. Without knowing the multilib
mapping, there is no obvious answer.
And in C for multilibs, there is typically only one set
of .h files (e.g. specification) and multiple implementations
(e.g. objects).
From my perspective, being technically correct is more
important than giving a user the direct answer in a file.
It is hard enough to always have the right multilib.
If you want to provide a utility to give a report that
answers these questions, that would be useful.
In fact, GCC even has something that is similar to this
report for C/C++ users.
gcc CPU_CFLAGS -dM -E - </dev/null
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.
I can see major differences when you have 32/64 bit multilibs
and those have to have different RTS source. I am sure there
are other cases like this. But the majority of multilibs are
based upon binary compatibility differences that the compiler
handles automatically. If you can handle endianness and
don't have RTS source code that is dependent on CPU
model differences, then that much should take care of itself
once the basic build infrastructure works multilib.
I think you will end up having to support generating different
source trees for each multilib variant to be safe and correct.
Handling some common differences like endianness in a clean
way that doesn't involve source variation should reduce the
cases though.
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?
This will work for native builds but may have problems on
cross builds where you can't run a program. I know for the
RTEMS g-soccon* file we have to run a program on target
hardware and capture the output.
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.
If you move the source to libada and start potentially
using different source combinations for different multilib
variants, then it does need to be on a branch.
But some of the patches so far seem like they would be OK
to commit on the mainline and minimize diffs.
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.
I would think this is the case. The multilib impacts the Ada
include path and the library search path just like with C.
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.
Your suggestion to split this code into its own file sounds right
and is another piece that could go onto the trunk without
causing harm and minimizes the differences.
Paolo
--joel