This is the mail archive of the
mailing list for the GCC project.
Re: [ada] rts support for alpha-linux
> On Tue, Jan 18, 2005 at 09:58:37PM +0100, Arnaud Charlet wrote:
> > Did you verify the differences in term of size and alignment by e.g.
> > compiling s-osinte.adb with -gnatR3 ?
> No. What does that do, and what would I be looking for?
Well, RTFM ;-)
-gnatR3 will output the memory layout (size, alignment) for each type and
object of the unit being compiled. So you can indeed confirm your suspicions
about bad alignment and/or bad sizes compared to the C structs.
> Many of the signal and errno numbers are different. A few of the
> other sigaction bits are different. Those are the main bits.
That's the first time I hear that signal numbers are different across linux
targets. That's a surprise. Maybe what you are saying is that some of
these values are actually wrong for all linux targets. That would indeed
make sense, and in this case, the correct fix is not to provide an alpha
variant, but clearly to fix the shared linux version.
Anyway, waiting for the diffs.
> > Same question for a-intnam.ads
> Alpha does not have SIGUNUSED, SIGLOST, or SIGSTKFLT. Neither do
> many other Linux targets, but s-osinte.adb isn't correct for them.
You can use the value 0 for non existent signals.
> Except for Tick, all little-endian 64-bit Linux targets should be
> the same. Add Bit_Order and all 64-bit Linux targets should be
> the same. Add the <limits.h> equivalent bits, and *all* Linux
> targets should be the same.
You listed quite a few exceptions. Also, we regularly add new constants in
the private part of system which may or may not be the same on all
little-endian 64 bit linux targets. We've already had the case in the past,
so I am talking from experience here, not from a theoretical point of view.
A simple example would be if we decide at some point to enable
Functions_Return_By_DSP under ia64 linux and that for some reason (e.g.
limitation or bug in the alpha back-end that no one is willing to look
at, or efficiency concerns) the alpha port does not want it, then you
will end up with an inconsistency.
> Yet more reasons that all of this data should be extracted from
> /usr/include instead of specified by hand.
We actually used to have a single system.ads file that was handled
automatically using GNAT attributes (see gcc/ada/system.ads), and this
proved to be insufficient, e.g. in the case of mapping priorities
(look for example in system-tru64.ads at Underlying_Priorities).