Re: [rfc] PowerPC ABI detection and overrides

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:

> Run the test four times:
> 
> - With -mabi=no-altivec and "set powerpc vector-abi generic".
> - With -mabi=altivec and "set powerpc vector-abi altivec".
> - With no ABI option and "set powerpc vector-abi auto".
> - With -mabi=altivec and "set powerpc vector-abi auto".
> 
> I think this covers all the sensible combinations.

This looks excellent!  

> You will need
> a relatively current GCC and very current linker for the auto tests
> to all pass.

Any chance of making those tests XFAIL instead of FAIL if the
toolchain is too old?

> Unfortunately the -mabi=no-altivec tests fail.  I filed GCC PR
> 33899 about this.  In the current scenario there is no way we
> can get this right.  I'm not going to commit this until I've at least
> discussed that with David.

Hmmm, yet another problem I wasn't aware of ...

However, this may not be quite as bad as it seems:  note that while
in your bugzilla report, you're refering to use of "__vector int",
this actually doesn't work:  the "AltiVec vector" types introduced
via the __vector or vector keywords are only available in the first
place if you use -maltivec; otherwise that code is rejected with a
syntax error anyway.

The third vector return ABI only comes into play if you explicitly
use the GCC-internal vector type via attribute ((vector_size (16))),
and do not use -maltivec.  In this situation, GCC will currently
indeed return vector values by reference, but the code will trigger
a compiler warning:
xxx.c:5: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee

I do not think that under these circumstances there can be any 
reasonable expectation for GDB to handle that situation.

So I would suggest that GDB interprets the "generic" case always
as the "-maltivec -mabi=no-altivec" situation, and expects 16-byte
vector return values in general-purpose registers.  This would also
fix our test cases (as those use the Altivec vector syntax and thus
reqiure -maltivec anyway).


> @@ -3027,6 +3049,9 @@ rs6000_gdbarch_init (struct gdbarch_info

> +#ifdef HAVE_ELF
> +  if (soft_float_flag == AUTO_BOOLEAN_AUTO && from_elf_exec)
> +    {
> +      switch (bfd_elf_get_obj_attr_int (info.abfd, OBJ_ATTR_GNU,
> +					Tag_GNU_Power_ABI_FP))

Hmmm, I would have hoped we could get away from directly refering
to the BFD in the gdbarch_init routine ...   It would be nicer to
more strictly distinguish between detecting ABI properties from
the BFD (in the *sniffer*), and installing an gdbarch handler 
supporting a particular set of ABI properties (in the gdbarch_init
routine).

This would allow to request a specific gdbarch in the situation
where you know exactly which ABI properties you need, but don't
have any BFD handy ...


(This doesn't mean I don't want this patch to go in -- I'm aware
that we're current looking at the BFD anyway.  I'm just wondering
if you have any ideas how this could be improved ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com