Re: [Patch] Fix ABI incompatibilities on s390x

[Jim Blandy <jimb@redhat.com>]

Gerhard Tonn <ton@de.ibm.com> writes:
> "Gerhard Tonn" <TON@de.ibm.com> writes:
> >> I don't think that it is worthwhile to duplicate the functions. The only
> >> difference between s390 and s390x is really the REGISTER_SIZE. I will
> >> rework the patch so that this becomes more clear. I will also address the
> >> other issues.
> 
> >Certainly, if two functions can be made identical by the appropriate
> >use of REGISTER_SIZE, then there's no reason to duplicate them.
> >However, I thought I had seen another sort of conditionality which is
> >definitely of the sort we are trying to avoid.
> 
> >I'll watch for your new patches.  Thanks again for your work.
> 
> Please find below the revised patch. The number of floating point registers is
> another difference between s390 and s390x besides the register size.
> 
> As soon as you have approved the patch  we will start the copyright assignment . I
> will let you know any progress.

I'm afraid I have the same concerns about this patch as I did about
the first one.

It seems that there are two main differences between the s390 and
s390x ABI's:
- the s390 registers are larger.
- the s390x does not have a special DOUBLE_ARG class of arguments that
  it handles specially.

Most of the first sort of difference you can account for using
REGISTER_SIZE, but there is one case that cannot be handled this way.
You handle this by testing GDB_TARGET_IS_ESAME.

Since there are several bits of code that know about the existence of
DOUBLE_ARGs (i.e., we have to exclude DOUBLE_ARGs from the other
classes of arguments), you handle each of those by testing
GDB_TARGET_IS_ESAME.

Please handle the first case by defining a function:

static int
is_power_of_two (unsigned int n)
{
  return ((n & (n-1)) == 0);
}

and then saying ! (is_power_of_two (length) && length <= REGISTER_SIZE) 
in pass_by_copy_ref.

Please handle the second case by explicitly calling is_double_arg from
is_simple_arg, and then change is_double_arg as follows:

static int
is_double_arg (struct type *type)
{
  unsigned length = TYPE_LENGTH (type);

  /* The s390x ABI doesn't handle DOUBLE_ARGS specially.  */
  if (GDB_TARGET_IS_ESAME)
    return 0;

  return ((is_integer_like (type)
           || is_struct_like (type))
          && length == 8);
}

I'll be happy to review the patch again once these changes have been
made.

A while back, I spent several weeks fixing bugs in the parameter
passing code of the s390 GDB port that had just been contributed ---
bugs that could have been found and fixed by anyone willing to run the
test suite.  But this is not unusual; of the half-dozen or so gdb
ports I've been asked to fix over the years, the parameter passing
code is the part that is most often broken.  Those sorts of problems
usually occupy the better part of the time required to bring the test
suite into good shape for a given architecture.  I think other GDB
developers with exposure to a broad range of architectures can cite
similar experiences.

So I think it is very important that we not waste future developers'
time by allowing the same sorts of coding practices that have led to
such poor reliability in the past.  As I said in my first review of
the patch, one of the hallmarks of parameter-passing code that will
not survive the test of time is code that is shared between several
ABI variants.  Each variant has its quirks (i.e., the special
handling, or lack thereof, for DOUBLE_ARG arguments), and its bugs
(which are not always carried from one variant to another, as the
double and float singleton bug was on the s390 family), and in the
end, being able to cope with each ABI as a separate entity is the
better approach.

What I'm suggesting above is a compromise, that at least localizes the
architecture tests to a single place, which is clearly related to the
important distinction between the ABI's.