Re: [PATCH 1/3] RISC-V: gdb.base/gnu_vector fixes.

[Jim Wilson <jimw@sifive.com>]

On Thu, Nov 8, 2018 at 7:43 AM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
> I struggled to understand what the difference between align and
> slot_align is in this patch, it feels like....

If you have an argument twice the size of xlen, with alignment twice
the size of xlen, then when we pass the first word, align is 2*xlen
and slot_align is xlen.

> .... you might be better off just passing a better value of align
> through here.  Testing on gdb.base/gnu_vector.exp shows that doing
> this fixes the same problem that your original patch fixes.

> -      int len = (ainfo->length > cinfo->xlen) ? cinfo->xlen : ainfo->length;
> +      int len = std::min (ainfo->length, cinfo->xlen);
> +      int align = std::max (ainfo->align, cinfo->xlen);

If you do this, and we keep the patch in riscv_assign_stack_location,
then we end up allocating 2*xlen bytes for the first xlen bytes of a
argument of size 2*len whcih is wrong.

I suppose you want to drop the riscv_assign_stack_location change too.
That could work, but that leaves arg_offset unaligned after allocating
the last argument.  Though it looks like the only problem with that is
some funny riscv_debug_infcall output.  It might say for instance that
we have 12 bytes of stack arguments for a 64-bit target, which doesn't
make any sense.  For a 64-bit target, stack arguments should always be
a multiple of 8 bytes.  Otherwise, this looks harmless, and this is a
problem that we already have, so this isn't anything broken by this
patch set.  I'll rewrite the patch this way.

Jim