* [commit] Use -mabi=altivec for AltiVec tests
@ 2007-10-21 13:05 Ulrich Weigand
2007-10-21 18:08 ` Daniel Jacobowitz
0 siblings, 1 reply; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-21 13:05 UTC (permalink / raw)
To: gdb-patches
Hello,
both altivec-abi.exp and altivec-regs.exp had a number of test cases
failing because the test case source code was compiled without using
the -mabi=altivec flag. As GDB expects the inferior to use the
AltiVec ABI, we need to compile the test case accordingly ...
Committed to mainline.
Bye,
Ulrich
ChangeLog:
* gdb.arch/altivec-abi.exp (compile_flags): Use -mabi=altivec when
compiling test case with GCC.
* gdb.arch/altivec-regs.exp (compile_flags): Likewise.
diff -urNp gdb-orig/gdb/testsuite/gdb.arch/altivec-abi.exp gdb-head/gdb/testsuite/gdb.arch/altivec-abi.exp
--- gdb-orig/gdb/testsuite/gdb.arch/altivec-abi.exp 2007-10-21 01:24:25.000000000 +0200
+++ gdb-head/gdb/testsuite/gdb.arch/altivec-abi.exp 2007-10-21 14:25:12.820540991 +0200
@@ -48,7 +48,7 @@ if [get_compiler_info $binfile] {
}
if [test_compiler_info gcc*] {
- set compile_flags "$compile_flags additional_flags=-maltivec"
+ set compile_flags "$compile_flags additional_flags=-maltivec additional_flags=-mabi=altivec"
} elseif [test_compiler_info xlc*] {
set compile_flags "$compile_flags additional_flags=-qaltivec"
} else {
diff -urNp gdb-orig/gdb/testsuite/gdb.arch/altivec-regs.exp gdb-head/gdb/testsuite/gdb.arch/altivec-regs.exp
--- gdb-orig/gdb/testsuite/gdb.arch/altivec-regs.exp 2007-10-21 14:24:45.702324095 +0200
+++ gdb-head/gdb/testsuite/gdb.arch/altivec-regs.exp 2007-10-21 14:25:12.824540415 +0200
@@ -48,7 +48,7 @@ if [get_compiler_info $binfile] {
}
if [test_compiler_info gcc*] {
- set compile_flags "$compile_flags additional_flags=-maltivec"
+ set compile_flags "$compile_flags additional_flags=-maltivec additional_flags=-mabi=altivec"
} elseif [test_compiler_info xlc*] {
set compile_flags "$compile_flags additional_flags=-qaltivec"
} else {
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-21 13:05 [commit] Use -mabi=altivec for AltiVec tests Ulrich Weigand
@ 2007-10-21 18:08 ` Daniel Jacobowitz
2007-10-21 19:37 ` Ulrich Weigand
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-21 18:08 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Sun, Oct 21, 2007 at 02:35:02PM +0200, Ulrich Weigand wrote:
> Hello,
>
> both altivec-abi.exp and altivec-regs.exp had a number of test cases
> failing because the test case source code was compiled without using
> the -mabi=altivec flag. As GDB expects the inferior to use the
> AltiVec ABI, we need to compile the test case accordingly ...
>
> Committed to mainline.
I don't think this is a good idea. -mabi=altivec is an ABI-changing
option; you're supposed to match the ABI of your system libraries.
It will work out OK in practice though since the stack alignment is
already large enough on powerpc-linux.
I committed a GCC HEAD patch several weeks ago to mark the vector ABI of
PowerPC object files. I also posted a linker patch to propogate this
into linked objects and I have the matching patch to GDB to
auto-detect the correct ABI and support both in GDB. That also
fixes this test.
Unfortunately the linker patch is hung up right now because it notices
this same dubious action (linking -mabi=altivec and -mabi=no-altivec
code) and warns about it. That causes a bunch of GCC testcase
failures. The GCC testcases in question use, but do not actually
need, -mabi=altivec; they just need a nasty bug in -maltivec
-mabi=no-altivec fixed and my patch for that didn't get any comments
:-(
Maybe I should commit the linker patch without the warning?
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-21 18:08 ` Daniel Jacobowitz
@ 2007-10-21 19:37 ` Ulrich Weigand
2007-10-24 20:47 ` Daniel Jacobowitz
2007-10-25 20:32 ` [rfc] PowerPC ABI detection and overrides Daniel Jacobowitz
0 siblings, 2 replies; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-21 19:37 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> I don't think this is a good idea. -mabi=altivec is an ABI-changing
> option; you're supposed to match the ABI of your system libraries.
> It will work out OK in practice though since the stack alignment is
> already large enough on powerpc-linux.
Sorry, I didn't consider this controversial, or I would have posted an RFC
first ... I understand it to be general practice to use -mabi=altivec
with applications on Linux, and that should be OK as long as no system
library interface using vector arguments is used. Is this a problem
in other environments?
However, if you prefer, I certainly have no objections to reverting the
patch (or maybe restricting it to Linux only) ...
> I committed a GCC HEAD patch several weeks ago to mark the vector ABI of
> PowerPC object files. I also posted a linker patch to propogate this
> into linked objects and I have the matching patch to GDB to
> auto-detect the correct ABI and support both in GDB. That also
> fixes this test.
Supporting both ABIs in GDB is certainly a good thing. However, the
point of this test case is to verify that GDB implements the AltiVec
ABI correctly, so IMO we really want to exercise that code path, not
bypass it. In fact, if we support both ABIs in GDB, we probably want
to run the test twice, once compiled with -mabi=altivec and once with
-mabi=no-altivec ...
> Unfortunately the linker patch is hung up right now because it notices
> this same dubious action (linking -mabi=altivec and -mabi=no-altivec
> code) and warns about it. That causes a bunch of GCC testcase
> failures. The GCC testcases in question use, but do not actually
> need, -mabi=altivec; they just need a nasty bug in -maltivec
> -mabi=no-altivec fixed and my patch for that didn't get any comments
> :-(
Can you point me to the patch in question? Maybe I can ping David ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-21 19:37 ` Ulrich Weigand
@ 2007-10-24 20:47 ` Daniel Jacobowitz
2007-10-29 18:04 ` Ulrich Weigand
2007-10-25 20:32 ` [rfc] PowerPC ABI detection and overrides Daniel Jacobowitz
1 sibling, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-24 20:47 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Sun, Oct 21, 2007 at 08:07:57PM +0200, Ulrich Weigand wrote:
> Sorry, I didn't consider this controversial, or I would have posted an RFC
> first ... I understand it to be general practice to use -mabi=altivec
> with applications on Linux, and that should be OK as long as no system
> library interface using vector arguments is used. Is this a problem
> in other environments?
>
> However, if you prefer, I certainly have no objections to reverting the
> patch (or maybe restricting it to Linux only) ...
My understanding (courtesy of Geoff Keating) is that on most PowerPC
targets this only affects the passing of vector registers. On some
(powerpc-eabi; I am not sure if there are others, but I do not know
of any) it increases the required stack alignment. If your CRT files
don't do this, then saving the vector registers may do bad things
to your stack frame.
I know my local GDB works both with -mabi=altivec and without it,
because I run this test in two multilibs :-)
For now, what do you think we should do about the option? Restrict it
to Linux?
> > Unfortunately the linker patch is hung up right now because it notices
> > this same dubious action (linking -mabi=altivec and -mabi=no-altivec
> > code) and warns about it. That causes a bunch of GCC testcase
> > failures. The GCC testcases in question use, but do not actually
> > need, -mabi=altivec; they just need a nasty bug in -maltivec
> > -mabi=no-altivec fixed and my patch for that didn't get any comments
> > :-(
>
> Can you point me to the patch in question? Maybe I can ping David ...
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html
Perhaps I should ping that now that the .gnu_attribute bit went in
separately. Actually, no, the patch predated my improved
understanding of the stack alignment magic. It might be right
for powerpc-eabi, but powerpc-linux actually does have a sufficiently
aligned stack so it ought to save them properly.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* [rfc] PowerPC ABI detection and overrides
2007-10-21 19:37 ` Ulrich Weigand
2007-10-24 20:47 ` Daniel Jacobowitz
@ 2007-10-25 20:32 ` Daniel Jacobowitz
2007-10-29 18:27 ` Ulrich Weigand
2007-10-30 20:12 ` Daniel Jacobowitz
1 sibling, 2 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-25 20:32 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Sun, Oct 21, 2007 at 08:07:57PM +0200, Ulrich Weigand wrote:
> Supporting both ABIs in GDB is certainly a good thing. However, the
> point of this test case is to verify that GDB implements the AltiVec
> ABI correctly, so IMO we really want to exercise that code path, not
> bypass it. In fact, if we support both ABIs in GDB, we probably want
> to run the test twice, once compiled with -mabi=altivec and once with
> -mabi=no-altivec ...
Here's what I had in mind.
The patch makes GDB look at ABI markings in ELF files for both hard
versus soft floating point and AltiVec versus SPE versus generic
vectors. There are also new commands to force the right behavior
and documentation for them.
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. You will need
a relatively current GCC and very current linker for the auto tests
to all pass.
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.
Tested on powerpc-linux, though there were some last minute
modifications; I should test it again before checking in anything.
I'm not sure if this deserves a NEWS entry.
--
Daniel Jacobowitz
CodeSourcery
2007-10-25 Daniel Jacobowitz <dan@codesourcery.com>
* ppc-sysv-tdep.c (ppc_sysv_abi_push_dummy_call): Check the selected
soft float and vector ABIs.
(do_ppc_sysv_return_value): Likewise. Correct argument types and
casts.
(ppc64_sysv_abi_push_dummy_call): Assert that floating point is
supported.
* ppc-tdep.h (enum powerpc_vector_abi): New.
(struct gdbarch_tdep): Add soft_float and vector_abi.
* rs6000-tdep.c (setpowerpccmdlist, showpowerpccmdlist)
(powerpc_soft_float_global, powerpc_vector_strings)
(powerpc_vector_abi_global, powerpc_vector_abi_string): New.
(rs6000_gdbarch_init): Check for soft-float and vector ABI markings.
(set_powerpc_command, show_powerpc_command, powerpc_set_soft_float)
(powerpc_set_vector_abi): New.
(_initialize_rs6000_tdep): Register "set powerpc" and "show powerpc"
commands.
* Makefile.in (elf_ppc_h): New.
(rs6000-tdep.o): Update.
* gdb.texinfo (PowerPC): Document "set powerpc vector-abi" and "set
powerpc soft-float".
* gdb.arch/altivec-abi.exp: Run multiple times for GCC. Test
"set powerpc vector-abi".
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.954
diff -u -p -r1.954 Makefile.in
--- Makefile.in 25 Oct 2007 17:52:31 -0000 1.954
+++ Makefile.in 25 Oct 2007 19:52:26 -0000
@@ -604,6 +604,7 @@ elf_bfd_h = $(BFD_SRC)/elf-bfd.h
elf_frv_h = $(INCLUDE_DIR)/elf/frv.h $(elf_reloc_macros_h)
elf_m32c_h = $(INCLUDE_DIR)/elf/m32c.h $(elf_reloc_macros_h)
elf_mep_h = $(INCLUDE_DIR)/elf/mep.h $(elf_reloc_macros_h)
+elf_ppc_h = $(INCLUDE_DIR)/elf/ppc.h $(elf_reloc_macros_h)
libaout_h = $(BFD_SRC)/libaout.h
libiberty_h = $(INCLUDE_DIR)/libiberty.h
libbfd_h = $(BFD_SRC)/libbfd.h
@@ -2578,7 +2579,7 @@ rs6000-tdep.o: rs6000-tdep.c $(defs_h) $
$(coff_xcoff_h) $(libxcoff_h) $(elf_bfd_h) $(solib_svr4_h) \
$(ppc_tdep_h) $(gdb_assert_h) $(dis_asm_h) $(trad_frame_h) \
$(frame_unwind_h) $(frame_base_h) $(rs6000_tdep_h) $(dwarf2_frame_h) \
- $(target_descriptions) $(user_regs_h) \
+ $(target_descriptions) $(user_regs_h) $(elf_ppc_h) \
$(powerpc_32_c) $(powerpc_403_c) $(powerpc_403gc_c) $(powerpc_505_c) \
$(powerpc_601_c) $(powerpc_602_c) $(powerpc_603_c) $(powerpc_604_c) \
$(powerpc_64_c) $(powerpc_7400_c) $(powerpc_750_c) $(powerpc_860_c) \
Index: ppc-sysv-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-sysv-tdep.c,v
retrieving revision 1.40
diff -u -p -r1.40 ppc-sysv-tdep.c
--- ppc-sysv-tdep.c 6 Sep 2007 20:21:16 -0000 1.40
+++ ppc-sysv-tdep.c 25 Oct 2007 19:52:27 -0000
@@ -104,8 +104,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
int len = TYPE_LENGTH (type);
const bfd_byte *val = value_contents (arg);
- if (TYPE_CODE (type) == TYPE_CODE_FLT
- && ppc_floating_point_unit_p (current_gdbarch) && len <= 8)
+ if (TYPE_CODE (type) == TYPE_CODE_FLT && len <= 8
+ && !tdep->soft_float)
{
/* Floating point value converted to "double" then
passed in an FP register, when the registers run out,
@@ -141,10 +141,11 @@ ppc_sysv_abi_push_dummy_call (struct gdb
argoffset += 8;
}
}
- else if (len == 8 && (TYPE_CODE (type) == TYPE_CODE_INT /* long long */
- || (!ppc_floating_point_unit_p (current_gdbarch) && TYPE_CODE (type) == TYPE_CODE_FLT))) /* double */
+ else if (len == 8
+ && (TYPE_CODE (type) == TYPE_CODE_INT /* long long */
+ || TYPE_CODE (type) == TYPE_CODE_FLT)) /* double */
{
- /* "long long" or "double" passed in an odd/even
+ /* "long long" or soft-float "double" passed in an odd/even
register pair with the low addressed word in the odd
register and the high addressed word in the even
register, or when the registers run out an 8 byte
@@ -184,7 +185,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
}
else if (len == 16
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_vr0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_ALTIVEC)
{
/* Vector parameter passed in an Altivec register, or
when that runs out, 16 byte aligned stack location. */
@@ -205,7 +207,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
}
else if (len == 8
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_ev0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_SPE)
{
/* Vector parameter passed in an e500 register, or when
that runs out, 8 byte aligned stack location. Note
@@ -337,14 +340,14 @@ ppc_sysv_abi_push_dummy_call (struct gdb
static enum return_value_convention
do_ppc_sysv_return_value (struct gdbarch *gdbarch, struct type *type,
- struct regcache *regcache, void *readbuf,
- const void *writebuf, int broken_gcc)
+ struct regcache *regcache, gdb_byte *readbuf,
+ const gdb_byte *writebuf, int broken_gcc)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
gdb_assert (tdep->wordsize == 4);
if (TYPE_CODE (type) == TYPE_CODE_FLT
&& TYPE_LENGTH (type) <= 8
- && ppc_floating_point_unit_p (gdbarch))
+ && !tdep->soft_float)
{
if (readbuf)
{
@@ -374,17 +377,17 @@ do_ppc_sysv_return_value (struct gdbarch
{
/* A long long, or a double stored in the 32 bit r3/r4. */
regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 3,
- (bfd_byte *) readbuf + 0);
+ readbuf + 0);
regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 4,
- (bfd_byte *) readbuf + 4);
+ readbuf + 4);
}
if (writebuf)
{
/* A long long, or a double stored in the 32 bit r3/r4. */
regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 3,
- (const bfd_byte *) writebuf + 0);
+ writebuf + 0);
regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 4,
- (const bfd_byte *) writebuf + 4);
+ writebuf + 4);
}
return RETURN_VALUE_REGISTER_CONVENTION;
}
@@ -417,7 +420,8 @@ do_ppc_sysv_return_value (struct gdbarch
}
if (TYPE_LENGTH (type) == 16
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_vr0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_ALTIVEC)
{
if (readbuf)
{
@@ -433,7 +437,8 @@ do_ppc_sysv_return_value (struct gdbarch
}
if (TYPE_LENGTH (type) == 8
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_ev0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_SPE)
{
/* The e500 ABI places return values for the 64-bit DSP types
(__ev64_opaque__) in r3. However, in GDB-speak, ev3
@@ -604,6 +609,11 @@ ppc64_sysv_abi_push_dummy_call (struct g
the possible values of tdep->wordsize. */
gdb_assert (tdep->wordsize == 8);
+ /* This function exists to support a calling convention that
+ requires floating-point registers. It shouldn't be used on
+ processors that lack them. */
+ gdb_assert (ppc_floating_point_unit_p (gdbarch));
+
/* By this stage in the proceedings, SP has been decremented by "red
zone size" + "struct return size". Fetch the stack-pointer from
before this and use that as the BACK_CHAIN. */
@@ -685,8 +695,7 @@ ppc64_sysv_abi_push_dummy_call (struct g
memory. */
if (write_pass)
{
- if (ppc_floating_point_unit_p (current_gdbarch)
- && freg <= 13)
+ if (freg <= 13)
{
gdb_byte regval[MAX_REGISTER_SIZE];
struct type *regtype
@@ -869,7 +878,7 @@ ppc64_sysv_abi_push_dummy_call (struct g
}
-/* The 64 bit ABI retun value convention.
+/* The 64 bit ABI return value convention.
Return non-zero if the return-value is stored in a register, return
0 if the return-value is instead stored on the stack (a.k.a.,
Index: ppc-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/ppc-tdep.h,v
retrieving revision 1.58
diff -u -p -r1.58 ppc-tdep.h
--- ppc-tdep.h 15 Oct 2007 19:49:53 -0000 1.58
+++ ppc-tdep.h 25 Oct 2007 19:52:27 -0000
@@ -136,9 +136,24 @@ extern void ppc_collect_fpregset (const
/* Private data that this module attaches to struct gdbarch. */
+/* Vector ABI used by the inferior. */
+enum powerpc_vector_abi
+{
+ POWERPC_VEC_AUTO,
+ POWERPC_VEC_GENERIC,
+ POWERPC_VEC_ALTIVEC,
+ POWERPC_VEC_SPE,
+ POWERPC_VEC_LAST
+};
+
struct gdbarch_tdep
{
- int wordsize; /* size in bytes of fixed-point word */
+ int wordsize; /* Size in bytes of fixed-point word. */
+ int soft_float; /* Avoid FP registers for arguments? */
+
+ /* How to pass vector arguments. Never set to AUTO or LAST. */
+ enum powerpc_vector_abi vector_abi;
+
int ppc_gp0_regnum; /* GPR register 0 */
int ppc_toc_regnum; /* TOC register */
int ppc_ps_regnum; /* Processor (or machine) status (%msr) */
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.293
diff -u -p -r1.293 rs6000-tdep.c
--- rs6000-tdep.c 21 Oct 2007 20:04:47 -0000 1.293
+++ rs6000-tdep.c 25 Oct 2007 19:52:27 -0000
@@ -49,6 +49,7 @@
#include "libxcoff.h"
#include "elf-bfd.h"
+#include "elf/ppc.h"
#include "solib-svr4.h"
#include "ppc-tdep.h"
@@ -77,6 +78,27 @@
#include "features/rs6000/powerpc-e500.c"
#include "features/rs6000/rs6000.c"
+/* The list of available "set powerpc ..." and "show powerpc ..."
+ commands. */
+static struct cmd_list_element *setpowerpccmdlist = NULL;
+static struct cmd_list_element *showpowerpccmdlist = NULL;
+
+static enum auto_boolean powerpc_soft_float_global = AUTO_BOOLEAN_AUTO;
+
+/* The vector ABI to use. Keep this in sync with powerpc_vector_abi. */
+static const char *powerpc_vector_strings[] =
+{
+ "auto",
+ "generic",
+ "altivec",
+ "spe",
+ NULL
+};
+
+/* A variable that can be configured by the user. */
+static enum powerpc_vector_abi powerpc_vector_abi_global = POWERPC_VEC_AUTO;
+static const char *powerpc_vector_abi_string = "auto";
+
/* If the kernel has to deliver a signal, it pushes a sigcontext
structure on the stack and then calls the signal handler, passing
the address of the sigcontext in an argument register. Usually
@@ -3027,6 +3049,9 @@ rs6000_gdbarch_init (struct gdbarch_info
bfd abfd;
int sysv_abi;
asection *sect;
+ enum auto_boolean soft_float_flag = powerpc_soft_float_global;
+ int soft_float;
+ enum powerpc_vector_abi vector_abi = powerpc_vector_abi_global;
int have_fpu = 1, have_spe = 0, have_mq = 0, have_altivec = 0;
int tdesc_wordsize = -1;
const struct target_desc *tdesc = info.target_desc;
@@ -3299,6 +3324,76 @@ rs6000_gdbarch_init (struct gdbarch_info
return NULL;
}
+#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))
+ {
+ case 1:
+ soft_float_flag = AUTO_BOOLEAN_FALSE;
+ break;
+ case 2:
+ soft_float_flag = AUTO_BOOLEAN_TRUE;
+ break;
+ default:
+ break;
+ }
+ }
+
+ if (vector_abi == POWERPC_VEC_AUTO && from_elf_exec)
+ {
+ switch (bfd_elf_get_obj_attr_int (info.abfd, OBJ_ATTR_GNU,
+ Tag_GNU_Power_ABI_Vector))
+ {
+ case 1:
+ vector_abi = POWERPC_VEC_GENERIC;
+ break;
+ case 2:
+ vector_abi = POWERPC_VEC_ALTIVEC;
+ break;
+ case 3:
+ vector_abi = POWERPC_VEC_SPE;
+ break;
+ default:
+ break;
+ }
+ }
+#endif
+
+ if (soft_float_flag == AUTO_BOOLEAN_TRUE)
+ soft_float = 1;
+ else if (soft_float_flag == AUTO_BOOLEAN_FALSE)
+ soft_float = 0;
+ else
+ soft_float = !have_fpu;
+
+ /* If we have a hard float binary or setting but no floating point
+ registers, downgrade to soft float anyway. We're still somewhat
+ useful in this scenario. */
+ if (!soft_float && !have_fpu)
+ soft_float = 1;
+
+ /* Similarly for vector registers. */
+ if (vector_abi == POWERPC_VEC_ALTIVEC && !have_altivec)
+ vector_abi = POWERPC_VEC_GENERIC;
+
+ if (vector_abi == POWERPC_VEC_SPE && !have_spe)
+ vector_abi = POWERPC_VEC_GENERIC;
+
+ if (vector_abi == POWERPC_VEC_AUTO)
+ {
+ if (have_altivec)
+ vector_abi = POWERPC_VEC_ALTIVEC;
+ else if (have_spe)
+ vector_abi = POWERPC_VEC_SPE;
+ else
+ vector_abi = POWERPC_VEC_GENERIC;
+ }
+
+ /* Do not limit the vector ABI based on available hardware, since we
+ do not yet know what hardware we'll decide we have. Yuck! FIXME! */
+
/* Find a candidate among extant architectures. */
for (arches = gdbarch_list_lookup_by_info (arches, &info);
arches != NULL;
@@ -3308,6 +3403,10 @@ rs6000_gdbarch_init (struct gdbarch_info
meaningful, because 64-bit CPUs can run in 32-bit mode. So, perform
separate word size check. */
tdep = gdbarch_tdep (arches->gdbarch);
+ if (tdep && tdep->soft_float != soft_float)
+ continue;
+ if (tdep && tdep->vector_abi != vector_abi)
+ continue;
if (tdep && tdep->wordsize == wordsize)
{
if (tdesc_data != NULL)
@@ -3326,6 +3425,8 @@ rs6000_gdbarch_init (struct gdbarch_info
tdep = XCALLOC (1, struct gdbarch_tdep);
tdep->wordsize = wordsize;
+ tdep->soft_float = soft_float;
+ tdep->vector_abi = vector_abi;
gdbarch = gdbarch_alloc (&info, tdep);
@@ -3525,6 +3626,61 @@ rs6000_dump_tdep (struct gdbarch *gdbarc
/* FIXME: Dump gdbarch_tdep. */
}
+/* PowerPC-specific commands. */
+
+static void
+set_powerpc_command (char *args, int from_tty)
+{
+ printf_unfiltered (_("\
+\"set powerpc\" must be followed by an appropriate subcommand.\n"));
+ help_list (setpowerpccmdlist, "set powerpc ", all_commands, gdb_stdout);
+}
+
+static void
+show_powerpc_command (char *args, int from_tty)
+{
+ cmd_show_list (showpowerpccmdlist, from_tty, "");
+}
+
+static void
+powerpc_set_soft_float (char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+ struct gdbarch_info info;
+
+ /* Update the architecture. */
+ gdbarch_info_init (&info);
+ if (!gdbarch_update_p (info))
+ internal_error (__FILE__, __LINE__, "could not update architecture");
+}
+
+static void
+powerpc_set_vector_abi (char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+ struct gdbarch_info info;
+ enum powerpc_vector_abi vector_abi;
+
+ for (vector_abi = POWERPC_VEC_AUTO;
+ vector_abi != POWERPC_VEC_LAST;
+ vector_abi++)
+ if (strcmp (powerpc_vector_abi_string,
+ powerpc_vector_strings[vector_abi]) == 0)
+ {
+ powerpc_vector_abi_global = vector_abi;
+ break;
+ }
+
+ if (vector_abi == POWERPC_VEC_LAST)
+ internal_error (__FILE__, __LINE__, _("Invalid vector ABI accepted: %s."),
+ powerpc_vector_abi_string);
+
+ /* Update the architecture. */
+ gdbarch_info_init (&info);
+ if (!gdbarch_update_p (info))
+ internal_error (__FILE__, __LINE__, "could not update architecture");
+}
+
/* Initialization code. */
extern initialize_file_ftype _initialize_rs6000_tdep; /* -Wmissing-prototypes */
@@ -3550,4 +3706,30 @@ _initialize_rs6000_tdep (void)
initialize_tdesc_powerpc_860 ();
initialize_tdesc_powerpc_e500 ();
initialize_tdesc_rs6000 ();
+
+ /* Add root prefix command for all "set powerpc"/"show powerpc"
+ commands. */
+ add_prefix_cmd ("powerpc", no_class, set_powerpc_command,
+ _("Various PowerPC-specific commands."),
+ &setpowerpccmdlist, "set powerpc ", 0, &setlist);
+
+ add_prefix_cmd ("powerpc", no_class, show_powerpc_command,
+ _("Various PowerPC-specific commands."),
+ &showpowerpccmdlist, "show powerpc ", 0, &showlist);
+
+ /* Add a command to allow the user to force the ABI. */
+ add_setshow_auto_boolean_cmd ("soft-float", class_support,
+ &powerpc_soft_float_global,
+ _("Set whether to use a soft-float ABI."),
+ _("Show whether to use a soft-float ABI."),
+ NULL,
+ powerpc_set_soft_float, NULL,
+ &setpowerpccmdlist, &showpowerpccmdlist);
+
+ add_setshow_enum_cmd ("vector-abi", class_support, powerpc_vector_strings,
+ &powerpc_vector_abi_string,
+ _("Set the vector ABI."),
+ _("Show the vector ABI."),
+ NULL, powerpc_set_vector_abi, NULL,
+ &setpowerpccmdlist, &showpowerpccmdlist);
}
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.440
diff -u -p -r1.440 gdb.texinfo
--- doc/gdb.texinfo 24 Oct 2007 21:05:36 -0000 1.440
+++ doc/gdb.texinfo 25 Oct 2007 19:52:29 -0000
@@ -14937,7 +14937,25 @@ Set suspend trace mode.
@node PowerPC
@subsection PowerPC
+@value{GDBN} provides the following PowerPC-specific commands:
+
@table @code
+@kindex set powerpc
+@item set powerpc soft-float
+@itemx show powerpc soft-float
+Force @value{GDBN} to use (or not use) a software floating point calling
+convention. By default, @value{GDBN} selects the calling convention based
+on the selected architecture and the provided executable file.
+
+@item set powerpc vector-abi
+@itemx show powerpc vector-abi
+Force @value{GDBN} to use the specified calling convention for vector
+arguments and return values. The valid options are @samp{auto};
+@samp{generic}, to avoid vector registers even if they are present;
+@samp{altivec}, to use AltiVec registers; and @samp{spe} to use SPE
+registers. By default, @value{GDBN} selects the calling convention
+based on the selected architecture and the provided executable file.
+
@kindex target dink32
@item target dink32 @var{dev}
DINK32 ROM monitor.
@@ -14955,7 +14973,7 @@ SDS monitor, running on a PowerPC board
@cindex SDS protocol
The following commands specific to the SDS protocol are supported
-by@value{GDBN}:
+by @value{GDBN}:
@table @code
@item set sdstimeout @var{nsec}
Index: testsuite/gdb.arch/altivec-abi.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/altivec-abi.exp,v
retrieving revision 1.12
diff -u -p -r1.12 altivec-abi.exp
--- testsuite/gdb.arch/altivec-abi.exp 21 Oct 2007 12:28:00 -0000 1.12
+++ testsuite/gdb.arch/altivec-abi.exp 25 Oct 2007 19:52:29 -0000
@@ -13,9 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
-# Please email any bugs, comments, and/or additions to this file to:
-# bug-gdb@prep.ai.mit.edu
-#
# Tests for Powerpc AltiVec ABI
@@ -28,9 +25,6 @@ if $tracelevel then {
# This file uses altivec-abi.c for input.
#
-set prms_id 0
-set bug_id 0
-
if {![istarget "powerpc*"] || [skip_altivec_tests]} then {
verbose "Skipping altivec abi tests."
verbose -log "Skipping altivec abi tests."
@@ -41,88 +35,105 @@ set testfile "altivec-abi"
set binfile ${objdir}/${subdir}/${testfile}
set srcfile ${testfile}.c
-set compile_flags {debug nowarnings}
if [get_compiler_info $binfile] {
warning "get_compiler failed"
return -1
}
-if [test_compiler_info gcc*] {
- set compile_flags "$compile_flags additional_flags=-maltivec additional_flags=-mabi=altivec"
-} elseif [test_compiler_info xlc*] {
- set compile_flags "$compile_flags additional_flags=-qaltivec"
-} else {
- warning "unknown compiler"
- return -1
-}
+proc altivec_abi_tests { extra_flags force_abi } {
+ global testfile binfile srcfile srcdir subdir
-if { [gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile} executable $compile_flags] != "" } {
- untested altivec-abi.exp
- return -1
-}
+ set compile_flags "debug nowarnings $extra_flags"
-gdb_start
-gdb_reinitialize_dir $srcdir/$subdir
-gdb_load ${binfile}
+ if { [gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile} executable $compile_flags] != "" } {
+ untested altivec-abi.exp
+ return -1
+ }
-#
-# Run to `main' where we begin our tests.
-#
+ gdb_exit
+ gdb_start
+ gdb_reinitialize_dir $srcdir/$subdir
+ gdb_load ${binfile}
+
+ # Run to `main' where we begin our tests.
+ if ![runto_main] then {
+ untested altivec-abi.exp
+ return -1
+ }
+
+ gdb_test "set powerpc vector-abi $force_abi"
+
+ gdb_test "b marker" "Breakpoint 2 at.*file.*altivec-abi.c, line \[0-9\]+." "break marker"
+ gdb_test "continue" "Breakpoint 2.*marker.*altivec-abi.c.*" "continue to marker"
+ gdb_test "finish" "Run till exit from .0.*marker.*at.*altivec-abi.c.*main \\(\\) at.*altivec-abi.c.*result = vec_func \\(vshort,.*goes in v2.*" "back to main (1)"
+
+ # now all the arguments of vec_fun are initialized
+
+ set pattern "vec_func .vshort_f=.111, 222, 333, 444, 555, 666, 777, 888., vushort_f=.100, 200, 300, 400, 500, 600, 700, 800., vint_f=.-10, -20, -30, -40., vuint_f=.1111, 2222, 3333, 4444., vchar_f=.abcdefghilmnopqr., vuchar_f=.ABCDEFGHILMNOPQR., vfloat_f=.1.25, 3.75, 5.5, 1.25., x_f=.1, 2, 3, 4, 5, 6, 7, 8., y_f=.12, 22, 32, 42., a_f=.vector of chars.., b_f=.5.5, 4.5, 3.75, 2.25., c_f=.1.25, 3.5, 5.5, 7.75., intv_on_stack_f=.12, 34, 56, 78.."
+
+ set pattern1 $pattern
+ append pattern1 " at.*altivec-abi.c.*vint_res = vec_add.*vint_f, intv_on_stack_f.;"
+
+ # Now let's call the function. This function has > 12 args,
+ # the last one will go on the stack.
+ gdb_test "p vec_func(vshort,vushort,vint,vuint,vchar,vuchar,vfloat,x,y,a,b,c,intv_on_stack)" \
+ ".\[0-9\]+ = .2, 2, 2, 2." "call inferior function with vectors (1) "
-if ![runto_main] then {
- gdb_suppress_tests
+ # Let's call the function again with dummy arguments. This is to clean
+ # up the contents of the vector registers before the next call.
+ gdb_test "p vec_func(vshort_d,vushort_d,vint_d,vuint_d,vchar_d,vuchar_d,vfloat_d,x_d,y_d,a_d,b_d,c_d,intv_on_stack_d)" \
+ ".\[0-9\]+ = .0, 0, 0, 0." "call inferior function with vectors (2) "
+
+ # Let's step into the function, to see if the args are printed correctly.
+ gdb_test "step" \
+ $pattern1 \
+ "step into vec_fun"
+
+ set pattern2 $pattern
+ append pattern2 " at.*altivec-abi.c.*main.*result = vec_func .vshort,.*goes in v2.*Value returned is.*= .2, 2, 2, 2."
+
+ # Let's see if the result is returned correctly.
+ gdb_test "finish" \
+ "Run till exit from .0.*$pattern2" \
+ "vector value returned correctly"
+
+ # can we print the args correctly for this function?
+ gdb_test "break struct_of_vector_func" "" ""
+
+ set pattern "struct_of_vector_func .vector_struct=.vshort1 = .1, 2, 3, 4, 5, 6, 7, 8., vshort2 = .11, 12, 13, 14, 15, 16, 17, 18., vshort3 = .21, 22, 23, 24, 25, 26, 27, 28., vshort4 = .31, 32, 33, 34, 35, 36, 37, 38... at.*altivec-abi.c.*"
+
+ gdb_test "continue" \
+ "Breakpoint 3, $pattern.*vector_struct.vshort1 = vec_add .vector_struct.vshort1, vector_struct.vshort2.;" \
+ "continue to struct_of_vector_func"
+
+ gdb_test "finish" \
+ "Run till exit from .0 $pattern\[ \r\n\]+main.*altivec-abi.c.*array_of_vector_func.*" \
+ "back to main (2)"
+
+ gdb_test "step" "" "step into array_of_vector_func"
+ gdb_test "p matrix\[0\]" ".*= .1, 2, 3, 4, 5, 6, 7, 8." "print first vector"
+ gdb_test "p matrix\[1\]" ".*= .11, 12, 13, 14, 15, 16, 17, 18." "print second vector"
+ gdb_test "p matrix\[2\]" ".*= .21, 22, 23, 24, 25, 26, 27, 28." "print third vector"
+ gdb_test "p matrix\[3\]" ".*= .31, 32, 33, 34, 35, 36, 37, 38." "print fourth vector"
}
-gdb_test "b marker" "Breakpoint 2 at.*file.*altivec-abi.c, line \[0-9\]+." "break marker"
-gdb_test "continue" "Breakpoint 2.*marker.*altivec-abi.c.*" "continue to marker"
-gdb_test "finish" "Run till exit from .0.*marker.*at.*altivec-abi.c.*main \\(\\) at.*altivec-abi.c.*result = vec_func \\(vshort,.*goes in v2.*" "back to main (1)"
-
-# now all the arguments of vec_fun are initialized
-
-set pattern "vec_func .vshort_f=.111, 222, 333, 444, 555, 666, 777, 888., vushort_f=.100, 200, 300, 400, 500, 600, 700, 800., vint_f=.-10, -20, -30, -40., vuint_f=.1111, 2222, 3333, 4444., vchar_f=.abcdefghilmnopqr., vuchar_f=.ABCDEFGHILMNOPQR., vfloat_f=.1.25, 3.75, 5.5, 1.25., x_f=.1, 2, 3, 4, 5, 6, 7, 8., y_f=.12, 22, 32, 42., a_f=.vector of chars.., b_f=.5.5, 4.5, 3.75, 2.25., c_f=.1.25, 3.5, 5.5, 7.75., intv_on_stack_f=.12, 34, 56, 78.."
-
-set pattern1 $pattern
-append pattern1 " at.*altivec-abi.c.*vint_res = vec_add.*vint_f, intv_on_stack_f.;"
-
-# Now let's call the function. This function has > 12 args,
-# the last one will go on the stack.
-gdb_test "p vec_func(vshort,vushort,vint,vuint,vchar,vuchar,vfloat,x,y,a,b,c,intv_on_stack)" \
-".\[0-9\]+ = .2, 2, 2, 2." "call inferior function with vectors (1) "
-
-# Let's call the function again with dummy arguments. This is to clean
-# up the contents of the vector registers before the next call.
-gdb_test "p vec_func(vshort_d,vushort_d,vint_d,vuint_d,vchar_d,vuchar_d,vfloat_d,x_d,y_d,a_d,b_d,c_d,intv_on_stack_d)" \
-".\[0-9\]+ = .0, 0, 0, 0." "call inferior function with vectors (2) "
-
-# Let's step into the function, to see if the args are printed correctly.
-gdb_test "step" \
- $pattern1 \
- "step into vec_fun"
-
-set pattern2 $pattern
-append pattern2 " at.*altivec-abi.c.*main.*result = vec_func .vshort,.*goes in v2.*Value returned is.*= .2, 2, 2, 2."
-
-# Let's see if the result is returned correctly.
-gdb_test "finish" \
- "Run till exit from .0.*$pattern2" \
- "vector value returned correctly"
-
-# can we print the args correctly for this function?
-gdb_test "break struct_of_vector_func" "" ""
-
-set pattern "struct_of_vector_func .vector_struct=.vshort1 = .1, 2, 3, 4, 5, 6, 7, 8., vshort2 = .11, 12, 13, 14, 15, 16, 17, 18., vshort3 = .21, 22, 23, 24, 25, 26, 27, 28., vshort4 = .31, 32, 33, 34, 35, 36, 37, 38... at.*altivec-abi.c.*"
-
-gdb_test "continue" \
- "Breakpoint 3, $pattern.*vector_struct.vshort1 = vec_add .vector_struct.vshort1, vector_struct.vshort2.;" \
- "continue to struct_of_vector_func"
-
-gdb_test "finish" \
- "Run till exit from .0 $pattern\[ \r\n\]+main.*altivec-abi.c.*array_of_vector_func.*" \
- "back to main (2)"
-
-gdb_test "step" "" "step into array_of_vector_func"
-gdb_test "p matrix\[0\]" ".*= .1, 2, 3, 4, 5, 6, 7, 8." "print first vector"
-gdb_test "p matrix\[1\]" ".*= .11, 12, 13, 14, 15, 16, 17, 18." "print second vector"
-gdb_test "p matrix\[2\]" ".*= .21, 22, 23, 24, 25, 26, 27, 28." "print third vector"
-gdb_test "p matrix\[3\]" ".*= .31, 32, 33, 34, 35, 36, 37, 38." "print fourth vector"
+if [test_compiler_info gcc*] {
+ set saved_prefix $pf_prefix
+ set pf_prefix "${saved_prefix} generic ABI, forced:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=no-altivec" "generic"
+
+ set pf_prefix "${saved_prefix} AltiVec ABI, forced:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=altivec" "altivec"
+
+ set pf_prefix "${saved_prefix} default ABI, auto:"
+ altivec_abi_tests "additional_flags=-maltivec" "auto"
+
+ set pf_prefix "${saved_prefix} AltiVec ABI, auto:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=altivec" "auto"
+} elseif [test_compiler_info xlc*] {
+ altivec_abi_tests "additional_flags=-qaltivec" "auto"
+} else {
+ warning "unknown compiler"
+ return -1
+}
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-24 20:47 ` Daniel Jacobowitz
@ 2007-10-29 18:04 ` Ulrich Weigand
2007-10-29 18:06 ` Daniel Jacobowitz
0 siblings, 1 reply; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-29 18:04 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> My understanding (courtesy of Geoff Keating) is that on most PowerPC
> targets this only affects the passing of vector registers. On some
> (powerpc-eabi; I am not sure if there are others, but I do not know
> of any) it increases the required stack alignment. If your CRT files
> don't do this, then saving the vector registers may do bad things
> to your stack frame.
Yes, that was my understanding as well.
> For now, what do you think we should do about the option? Restrict it
> to Linux?
I think we should leave the option in, but for Linux only -- using
-mabi=altivec is supposed to work on Linux, and using it has the
effect of not only reducing testsuite FAILs, but actually in fact
testing the existing GDB code paths.
That is, unless we go right ahead and check your ABI detection
patch in; this would solve the problem in an even better way ...
Would you like me to check in the temporary fix, or would you
prefer to simply check in your patch?
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html
>
> Perhaps I should ping that now that the .gnu_attribute bit went in
> separately. Actually, no, the patch predated my improved
> understanding of the stack alignment magic. It might be right
> for powerpc-eabi, but powerpc-linux actually does have a sufficiently
> aligned stack so it ought to save them properly.
OK, I see. That is indeed a serious bug; I wasn't aware of that.
It would appear that the ABI defined by -mabi=no-altivec is currently
inconsistent with itself, so this absolutely needs to be fixed.
However, we should keep in mind the goal of being able to link
code built with -mabi=altivec and code built with -mabi=no-altivec,
as long as the interfaces between the two do not involve vector types.
This implies that -mabi=altivec and -mabi=no-altivec at least agree
on which registers are considered call-saved and which are considered
call-clobbered. Your patch would break that.
I'd suggest to either keep this part of the ABI unchanged between the
two, i.e. save/restore vr20..vr31 even in -mabi=no-altivec mode; or
else (if saving/restoring proves difficult), treat vr20..vr31 as
completely reserved and never use them, as is done by current GCC
mainline for AltiVec on AIX.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-29 18:04 ` Ulrich Weigand
@ 2007-10-29 18:06 ` Daniel Jacobowitz
2007-10-29 18:32 ` Ulrich Weigand
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-29 18:06 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Mon, Oct 29, 2007 at 06:57:47PM +0100, Ulrich Weigand wrote:
> > For now, what do you think we should do about the option? Restrict it
> > to Linux?
>
> I think we should leave the option in, but for Linux only -- using
> -mabi=altivec is supposed to work on Linux, and using it has the
> effect of not only reducing testsuite FAILs, but actually in fact
> testing the existing GDB code paths.
>
> That is, unless we go right ahead and check your ABI detection
> patch in; this would solve the problem in an even better way ...
>
> Would you like me to check in the temporary fix, or would you
> prefer to simply check in your patch?
I think I will check in my patch, but reduce the number of test
cases a bit. I'd like to test only two: -mabi=altivec + "set powerpc
vector-abi altivec", and -mabi=altivec + "set powerpc vector-abi
auto". The former should always pass. The latter will pass if GCC
and LD are new enough. Sound OK?
I don't want to test the non-AltiVec-ABI bits because they do not seem
to be sensibly defined. I filed PR 33899 last week, which shows
the -mabi=no-altivec ABI changing based on -maltivec. We can't and
shouldn't detect that.
> However, we should keep in mind the goal of being able to link
> code built with -mabi=altivec and code built with -mabi=no-altivec,
> as long as the interfaces between the two do not involve vector types.
> This implies that -mabi=altivec and -mabi=no-altivec at least agree
> on which registers are considered call-saved and which are considered
> call-clobbered. Your patch would break that.
>
> I'd suggest to either keep this part of the ABI unchanged between the
> two, i.e. save/restore vr20..vr31 even in -mabi=no-altivec mode; or
> else (if saving/restoring proves difficult), treat vr20..vr31 as
> completely reserved and never use them, as is done by current GCC
> mainline for AltiVec on AIX.
Right. I thought about this for a couple of days, and we should be
able to save and restore them. There's no reason it has to be
predicated on -mabi=altivec.
Of course, any existing -maltivec -mabi=no-altivec code will still
have to be rebuilt. It's terminally broken.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-25 20:32 ` [rfc] PowerPC ABI detection and overrides Daniel Jacobowitz
@ 2007-10-29 18:27 ` Ulrich Weigand
2007-10-29 18:38 ` Daniel Jacobowitz
2007-10-30 20:12 ` Daniel Jacobowitz
1 sibling, 1 reply; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-29 18:27 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [commit] Use -mabi=altivec for AltiVec tests
2007-10-29 18:06 ` Daniel Jacobowitz
@ 2007-10-29 18:32 ` Ulrich Weigand
0 siblings, 0 replies; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-29 18:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> I think I will check in my patch, but reduce the number of test
> cases a bit. I'd like to test only two: -mabi=altivec + "set powerpc
> vector-abi altivec", and -mabi=altivec + "set powerpc vector-abi
> auto". The former should always pass. The latter will pass if GCC
> and LD are new enough. Sound OK?
>
> I don't want to test the non-AltiVec-ABI bits because they do not seem
> to be sensibly defined. I filed PR 33899 last week, which shows
> the -mabi=no-altivec ABI changing based on -maltivec. We can't and
> shouldn't detect that.
I'm not sure the situation is actually that bad; see the other mail
I just sent ...
I think we *should* have -mabi=no-altivec test, and treat vector
returns always as the -maltivec -mabi=no-altivec case in that
situation.
> Right. I thought about this for a couple of days, and we should be
> able to save and restore them. There's no reason it has to be
> predicated on -mabi=altivec.
Yes. If you look at the comment in front of rs6000_stack_info,
saving Altivec registers for eabi targets should actually be
supported. Not sure if that is actually implemented correctly
in the code ... (For Linux there shouldn't be a problem anyway.)
> Of course, any existing -maltivec -mabi=no-altivec code will still
> have to be rebuilt. It's terminally broken.
Maybe not completely; there are two failure modes: one, the caller
currently incorrectly assumes its callees save/restore vr0..vr19 --
this leads to a bug that is immediately detected, so there probably
isn't a lot of broken code out there; and two, the callee currently
incorrectly does not even save vr20..vr31. This second case could
cause silently broken code out there, but it is probably rare, as
GCC will start allocating registers from vr0 up, so you'd have to
have -maltivec -mabi=no-altivec code that uses more than 20 Altivec
registers in a single function ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-29 18:27 ` Ulrich Weigand
@ 2007-10-29 18:38 ` Daniel Jacobowitz
2007-10-29 19:02 ` Ulrich Weigand
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-29 18:38 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Mon, Oct 29, 2007 at 07:11:27PM +0100, Ulrich Weigand wrote:
> > 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?
Most will pass anyway. The default ABI selection is going to be
AltiVec because the default set of registers include AltiVec
registers. I'll try to find some tools I can use to confirm that
before I check it in though.
I can probably come up with an XFAIL approach. I'll need some other
way to check that the attributes are present. Maybe objdump.
> 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.
Thanks, I'd forgotten about that.
> 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).
Interesting. Very interesting. I'll double-check that this works
and switch to it if it does. Then maybe I can test more of the cases.
> 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 ...
Can you give me an example of when you want to do that? In general
I've been moving away from it - there's too much extra bookkeeping
that the BFD does for us.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-29 18:38 ` Daniel Jacobowitz
@ 2007-10-29 19:02 ` Ulrich Weigand
2007-10-29 19:16 ` Daniel Jacobowitz
0 siblings, 1 reply; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-29 19:02 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> > 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 ...
>
> Can you give me an example of when you want to do that? In general
> I've been moving away from it - there's too much extra bookkeeping
> that the BFD does for us.
The situation came up in the context of the multi-architecture
Cell debugger, where you have to switch between SPU and PPC gdbarchs.
Now, in most case, you'll have an appropriate BFD available anyway,
but in some cases you don't: e.g. when debugging a "stand-alone"
SPU executable, the only BFD you have at start-up is SPU, but the
inferior process is actually still a PPC, and the underlying
infrastucture has in fact loaded PPC-side ld.so and libraries.
In this situation, I want to get at those by starting from the
PT_DYNAMIC header retrieved from the AT_PHDR AUXV entries, and
finding my way to the ld.so structures. But to even properly
access the target, I need to switch to a PPC gdbarch even before
I have any PPC BFD available.
Thinking about the problem I had at the time, maybe the real issue
is that those features detected from the BFD are not considered
as distinuishing factors when deciding whether to set up a new
gdbarch or return a cached one:
/* Find a candidate among extant architectures. */
for (arches = gdbarch_list_lookup_by_info (arches, &info);
arches != NULL;
arches = gdbarch_list_lookup_by_info (arches->next, &info))
{
/* Word size in the various PowerPC bfd_arch_info structs isn't
meaningful, because 64-bit CPUs can run in 32-bit mode. So, perform
separate word size check. */
tdep = gdbarch_tdep (arches->gdbarch);
if (tdep && tdep->wordsize == wordsize)
{
if (tdesc_data != NULL)
tdesc_data_cleanup (tdesc_data);
return arches->gdbarch;
}
}
Note that gdbarch_list_lookup_by_info ignores the info.abfd field.
This means that if you first looked up any PPC gdbarch without specifying
a BFD, and later on you look up a PPC gdbarch with BFD, you'll get that
first gdbarch returned from the cache, even though it doesn't actually
fit the current properties.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-29 19:02 ` Ulrich Weigand
@ 2007-10-29 19:16 ` Daniel Jacobowitz
2007-10-29 19:27 ` Ulrich Weigand
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-29 19:16 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On Mon, Oct 29, 2007 at 07:59:00PM +0100, Ulrich Weigand wrote:
> Thinking about the problem I had at the time, maybe the real issue
> is that those features detected from the BFD are not considered
> as distinuishing factors when deciding whether to set up a new
> gdbarch or return a cached one:
>
> /* Find a candidate among extant architectures. */
> for (arches = gdbarch_list_lookup_by_info (arches, &info);
> arches != NULL;
> arches = gdbarch_list_lookup_by_info (arches->next, &info))
> {
> /* Word size in the various PowerPC bfd_arch_info structs isn't
> meaningful, because 64-bit CPUs can run in 32-bit mode. So, perform
> separate word size check. */
> tdep = gdbarch_tdep (arches->gdbarch);
> if (tdep && tdep->wordsize == wordsize)
> {
> if (tdesc_data != NULL)
> tdesc_data_cleanup (tdesc_data);
> return arches->gdbarch;
> }
> }
>
>
> Note that gdbarch_list_lookup_by_info ignores the info.abfd field.
> This means that if you first looked up any PPC gdbarch without specifying
> a BFD, and later on you look up a PPC gdbarch with BFD, you'll get that
> first gdbarch returned from the cache, even though it doesn't actually
> fit the current properties.
Ignoring abfd is deliberate; we should be able to construct the same
arch with or without a BFD. But ignoring things derived from abfd is
a bug indeed. The MIPS target stashes ELF flags in its tdep structure
for this reason. PowerPC may not need that heavyweight check, but it
does need some other things, e.g., sysv_abi. Actually that's the only
one that I see that ought to be checked. Maybe that will fix the bug?
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-29 19:16 ` Daniel Jacobowitz
@ 2007-10-29 19:27 ` Ulrich Weigand
0 siblings, 0 replies; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-29 19:27 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> Ignoring abfd is deliberate; we should be able to construct the same
> arch with or without a BFD. But ignoring things derived from abfd is
> a bug indeed. The MIPS target stashes ELF flags in its tdep structure
> for this reason. PowerPC may not need that heavyweight check, but it
> does need some other things, e.g., sysv_abi. Actually that's the only
> one that I see that ought to be checked. Maybe that will fix the bug?
Yes, the bug I had was related to sysv_abi. And in fact, sysv_abi should
be fully detectable simply from looking at info.osabi, it should IMO not
be computed independently from the BFD. That's why I thought the proper
way to fix this problem was to stop looking directly at the BFD ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-25 20:32 ` [rfc] PowerPC ABI detection and overrides Daniel Jacobowitz
2007-10-29 18:27 ` Ulrich Weigand
@ 2007-10-30 20:12 ` Daniel Jacobowitz
2007-10-30 21:12 ` Ulrich Weigand
1 sibling, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2007-10-30 20:12 UTC (permalink / raw)
To: Ulrich Weigand, gdb-patches
On Thu, Oct 25, 2007 at 03:59:32PM -0400, Daniel Jacobowitz wrote:
> The patch makes GDB look at ABI markings in ELF files for both hard
> versus soft floating point and AltiVec versus SPE versus generic
> vectors. There are also new commands to force the right behavior
> and documentation for them.
Here's what I checked in. This skips some of the tests when using ELF
without ABI markings, but still runs enough to be useful - the tests
fail in a way that's hard to XFAIL, since the generic ABI uses
pass by reference so we end up with bad pointers.
Tested on powerpc-linux using gdbserver, -maltivec, -mabi=altivec.
Checked in.
--
Daniel Jacobowitz
CodeSourcery
2007-10-30 Daniel Jacobowitz <dan@codesourcery.com>
* ppc-sysv-tdep.c (ppc_sysv_abi_push_dummy_call): Check the selected
soft float and vector ABIs. Support the generic vector ABI for
AltiVec types.
(do_ppc_sysv_return_value): Likewise. Correct argument types and
casts.
(ppc64_sysv_abi_push_dummy_call): Assert that floating point is
supported.
* ppc-tdep.h (enum powerpc_vector_abi): New.
(struct gdbarch_tdep): Add soft_float and vector_abi.
* rs6000-tdep.c (setpowerpccmdlist, showpowerpccmdlist)
(powerpc_soft_float_global, powerpc_vector_strings)
(powerpc_vector_abi_global, powerpc_vector_abi_string): New.
(rs6000_gdbarch_init): Check for soft-float and vector ABI markings.
(set_powerpc_command, show_powerpc_command, powerpc_set_soft_float)
(powerpc_set_vector_abi): New.
(_initialize_rs6000_tdep): Register "set powerpc" and "show powerpc"
commands.
* Makefile.in (elf_ppc_h): New.
(rs6000-tdep.o): Update.
2007-10-30 Daniel Jacobowitz <dan@codesourcery.com>
* gdb.texinfo (PowerPC): Document "set powerpc vector-abi" and "set
powerpc soft-float".
2007-10-30 Daniel Jacobowitz <dan@codesourcery.com>
* gdb.arch/altivec-abi.exp: Run multiple times for GCC on GNU/Linux.
Test "set powerpc vector-abi". Skip auto-detection tests for old
toolchains.
Index: Makefile.in
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/Makefile.in,v
retrieving revision 1.954
diff -u -p -r1.954 Makefile.in
--- Makefile.in 25 Oct 2007 17:52:31 -0000 1.954
+++ Makefile.in 30 Oct 2007 15:06:46 -0000
@@ -604,6 +604,7 @@ elf_bfd_h = $(BFD_SRC)/elf-bfd.h
elf_frv_h = $(INCLUDE_DIR)/elf/frv.h $(elf_reloc_macros_h)
elf_m32c_h = $(INCLUDE_DIR)/elf/m32c.h $(elf_reloc_macros_h)
elf_mep_h = $(INCLUDE_DIR)/elf/mep.h $(elf_reloc_macros_h)
+elf_ppc_h = $(INCLUDE_DIR)/elf/ppc.h $(elf_reloc_macros_h)
libaout_h = $(BFD_SRC)/libaout.h
libiberty_h = $(INCLUDE_DIR)/libiberty.h
libbfd_h = $(BFD_SRC)/libbfd.h
@@ -2578,7 +2579,7 @@ rs6000-tdep.o: rs6000-tdep.c $(defs_h) $
$(coff_xcoff_h) $(libxcoff_h) $(elf_bfd_h) $(solib_svr4_h) \
$(ppc_tdep_h) $(gdb_assert_h) $(dis_asm_h) $(trad_frame_h) \
$(frame_unwind_h) $(frame_base_h) $(rs6000_tdep_h) $(dwarf2_frame_h) \
- $(target_descriptions) $(user_regs_h) \
+ $(target_descriptions) $(user_regs_h) $(elf_ppc_h) \
$(powerpc_32_c) $(powerpc_403_c) $(powerpc_403gc_c) $(powerpc_505_c) \
$(powerpc_601_c) $(powerpc_602_c) $(powerpc_603_c) $(powerpc_604_c) \
$(powerpc_64_c) $(powerpc_7400_c) $(powerpc_750_c) $(powerpc_860_c) \
Index: ppc-sysv-tdep.c
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/ppc-sysv-tdep.c,v
retrieving revision 1.40
diff -u -p -r1.40 ppc-sysv-tdep.c
--- ppc-sysv-tdep.c 6 Sep 2007 20:21:16 -0000 1.40
+++ ppc-sysv-tdep.c 30 Oct 2007 15:38:38 -0000
@@ -104,8 +104,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
int len = TYPE_LENGTH (type);
const bfd_byte *val = value_contents (arg);
- if (TYPE_CODE (type) == TYPE_CODE_FLT
- && ppc_floating_point_unit_p (current_gdbarch) && len <= 8)
+ if (TYPE_CODE (type) == TYPE_CODE_FLT && len <= 8
+ && !tdep->soft_float)
{
/* Floating point value converted to "double" then
passed in an FP register, when the registers run out,
@@ -141,10 +141,11 @@ ppc_sysv_abi_push_dummy_call (struct gdb
argoffset += 8;
}
}
- else if (len == 8 && (TYPE_CODE (type) == TYPE_CODE_INT /* long long */
- || (!ppc_floating_point_unit_p (current_gdbarch) && TYPE_CODE (type) == TYPE_CODE_FLT))) /* double */
+ else if (len == 8
+ && (TYPE_CODE (type) == TYPE_CODE_INT /* long long */
+ || TYPE_CODE (type) == TYPE_CODE_FLT)) /* double */
{
- /* "long long" or "double" passed in an odd/even
+ /* "long long" or soft-float "double" passed in an odd/even
register pair with the low addressed word in the odd
register and the high addressed word in the even
register, or when the registers run out an 8 byte
@@ -184,7 +185,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
}
else if (len == 16
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_vr0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_ALTIVEC)
{
/* Vector parameter passed in an Altivec register, or
when that runs out, 16 byte aligned stack location. */
@@ -205,7 +207,8 @@ ppc_sysv_abi_push_dummy_call (struct gdb
}
else if (len == 8
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_ev0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_SPE)
{
/* Vector parameter passed in an e500 register, or when
that runs out, 8 byte aligned stack location. Note
@@ -239,9 +242,15 @@ ppc_sysv_abi_push_dummy_call (struct gdb
|| TYPE_CODE (type) == TYPE_CODE_STRUCT
|| TYPE_CODE (type) == TYPE_CODE_UNION)
{
- /* Structs and large values are put on an 8 byte
- aligned stack ... */
- structoffset = align_up (structoffset, 8);
+ /* Structs and large values are put in an
+ aligned stack slot ... */
+ if (TYPE_CODE (type) == TYPE_CODE_ARRAY
+ && TYPE_VECTOR (type)
+ && len >= 16)
+ structoffset = align_up (structoffset, 16);
+ else
+ structoffset = align_up (structoffset, 8);
+
if (write_pass)
write_memory (sp + structoffset, val, len);
/* ... and then a "word" pointing to that address is
@@ -337,14 +346,14 @@ ppc_sysv_abi_push_dummy_call (struct gdb
static enum return_value_convention
do_ppc_sysv_return_value (struct gdbarch *gdbarch, struct type *type,
- struct regcache *regcache, void *readbuf,
- const void *writebuf, int broken_gcc)
+ struct regcache *regcache, gdb_byte *readbuf,
+ const gdb_byte *writebuf, int broken_gcc)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
gdb_assert (tdep->wordsize == 4);
if (TYPE_CODE (type) == TYPE_CODE_FLT
&& TYPE_LENGTH (type) <= 8
- && ppc_floating_point_unit_p (gdbarch))
+ && !tdep->soft_float)
{
if (readbuf)
{
@@ -374,17 +383,17 @@ do_ppc_sysv_return_value (struct gdbarch
{
/* A long long, or a double stored in the 32 bit r3/r4. */
regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 3,
- (bfd_byte *) readbuf + 0);
+ readbuf + 0);
regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 4,
- (bfd_byte *) readbuf + 4);
+ readbuf + 4);
}
if (writebuf)
{
/* A long long, or a double stored in the 32 bit r3/r4. */
regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 3,
- (const bfd_byte *) writebuf + 0);
+ writebuf + 0);
regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 4,
- (const bfd_byte *) writebuf + 4);
+ writebuf + 4);
}
return RETURN_VALUE_REGISTER_CONVENTION;
}
@@ -417,7 +426,8 @@ do_ppc_sysv_return_value (struct gdbarch
}
if (TYPE_LENGTH (type) == 16
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_vr0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_ALTIVEC)
{
if (readbuf)
{
@@ -431,9 +441,42 @@ do_ppc_sysv_return_value (struct gdbarch
}
return RETURN_VALUE_REGISTER_CONVENTION;
}
+ if (TYPE_LENGTH (type) == 16
+ && TYPE_CODE (type) == TYPE_CODE_ARRAY
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_GENERIC)
+ {
+ /* GCC -maltivec -mabi=no-altivec returns vectors in r3/r4/r5/r6.
+ GCC without AltiVec returns them in memory, but it warns about
+ ABI risks in that case; we don't try to support it. */
+ if (readbuf)
+ {
+ regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 3,
+ readbuf + 0);
+ regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 4,
+ readbuf + 4);
+ regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 5,
+ readbuf + 8);
+ regcache_cooked_read (regcache, tdep->ppc_gp0_regnum + 6,
+ readbuf + 12);
+ }
+ if (writebuf)
+ {
+ regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 3,
+ writebuf + 0);
+ regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 4,
+ writebuf + 4);
+ regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 5,
+ writebuf + 8);
+ regcache_cooked_write (regcache, tdep->ppc_gp0_regnum + 6,
+ writebuf + 12);
+ }
+ return RETURN_VALUE_REGISTER_CONVENTION;
+ }
if (TYPE_LENGTH (type) == 8
&& TYPE_CODE (type) == TYPE_CODE_ARRAY
- && TYPE_VECTOR (type) && tdep->ppc_ev0_regnum >= 0)
+ && TYPE_VECTOR (type)
+ && tdep->vector_abi == POWERPC_VEC_SPE)
{
/* The e500 ABI places return values for the 64-bit DSP types
(__ev64_opaque__) in r3. However, in GDB-speak, ev3
@@ -604,6 +647,11 @@ ppc64_sysv_abi_push_dummy_call (struct g
the possible values of tdep->wordsize. */
gdb_assert (tdep->wordsize == 8);
+ /* This function exists to support a calling convention that
+ requires floating-point registers. It shouldn't be used on
+ processors that lack them. */
+ gdb_assert (ppc_floating_point_unit_p (gdbarch));
+
/* By this stage in the proceedings, SP has been decremented by "red
zone size" + "struct return size". Fetch the stack-pointer from
before this and use that as the BACK_CHAIN. */
@@ -685,8 +733,7 @@ ppc64_sysv_abi_push_dummy_call (struct g
memory. */
if (write_pass)
{
- if (ppc_floating_point_unit_p (current_gdbarch)
- && freg <= 13)
+ if (freg <= 13)
{
gdb_byte regval[MAX_REGISTER_SIZE];
struct type *regtype
@@ -869,7 +916,7 @@ ppc64_sysv_abi_push_dummy_call (struct g
}
-/* The 64 bit ABI retun value convention.
+/* The 64 bit ABI return value convention.
Return non-zero if the return-value is stored in a register, return
0 if the return-value is instead stored on the stack (a.k.a.,
Index: ppc-tdep.h
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/ppc-tdep.h,v
retrieving revision 1.59
diff -u -p -r1.59 ppc-tdep.h
--- ppc-tdep.h 29 Oct 2007 20:26:42 -0000 1.59
+++ ppc-tdep.h 30 Oct 2007 15:06:46 -0000
@@ -157,9 +157,24 @@ extern void ppc_collect_vrregset (const
/* Private data that this module attaches to struct gdbarch. */
+/* Vector ABI used by the inferior. */
+enum powerpc_vector_abi
+{
+ POWERPC_VEC_AUTO,
+ POWERPC_VEC_GENERIC,
+ POWERPC_VEC_ALTIVEC,
+ POWERPC_VEC_SPE,
+ POWERPC_VEC_LAST
+};
+
struct gdbarch_tdep
{
- int wordsize; /* size in bytes of fixed-point word */
+ int wordsize; /* Size in bytes of fixed-point word. */
+ int soft_float; /* Avoid FP registers for arguments? */
+
+ /* How to pass vector arguments. Never set to AUTO or LAST. */
+ enum powerpc_vector_abi vector_abi;
+
int ppc_gp0_regnum; /* GPR register 0 */
int ppc_toc_regnum; /* TOC register */
int ppc_ps_regnum; /* Processor (or machine) status (%msr) */
Index: rs6000-tdep.c
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.294
diff -u -p -r1.294 rs6000-tdep.c
--- rs6000-tdep.c 29 Oct 2007 20:26:42 -0000 1.294
+++ rs6000-tdep.c 30 Oct 2007 15:06:46 -0000
@@ -49,6 +49,7 @@
#include "libxcoff.h"
#include "elf-bfd.h"
+#include "elf/ppc.h"
#include "solib-svr4.h"
#include "ppc-tdep.h"
@@ -77,6 +78,27 @@
#include "features/rs6000/powerpc-e500.c"
#include "features/rs6000/rs6000.c"
+/* The list of available "set powerpc ..." and "show powerpc ..."
+ commands. */
+static struct cmd_list_element *setpowerpccmdlist = NULL;
+static struct cmd_list_element *showpowerpccmdlist = NULL;
+
+static enum auto_boolean powerpc_soft_float_global = AUTO_BOOLEAN_AUTO;
+
+/* The vector ABI to use. Keep this in sync with powerpc_vector_abi. */
+static const char *powerpc_vector_strings[] =
+{
+ "auto",
+ "generic",
+ "altivec",
+ "spe",
+ NULL
+};
+
+/* A variable that can be configured by the user. */
+static enum powerpc_vector_abi powerpc_vector_abi_global = POWERPC_VEC_AUTO;
+static const char *powerpc_vector_abi_string = "auto";
+
/* If the kernel has to deliver a signal, it pushes a sigcontext
structure on the stack and then calls the signal handler, passing
the address of the sigcontext in an argument register. Usually
@@ -3145,6 +3167,9 @@ rs6000_gdbarch_init (struct gdbarch_info
bfd abfd;
int sysv_abi;
asection *sect;
+ enum auto_boolean soft_float_flag = powerpc_soft_float_global;
+ int soft_float;
+ enum powerpc_vector_abi vector_abi = powerpc_vector_abi_global;
int have_fpu = 1, have_spe = 0, have_mq = 0, have_altivec = 0;
int tdesc_wordsize = -1;
const struct target_desc *tdesc = info.target_desc;
@@ -3417,6 +3442,76 @@ rs6000_gdbarch_init (struct gdbarch_info
return NULL;
}
+#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))
+ {
+ case 1:
+ soft_float_flag = AUTO_BOOLEAN_FALSE;
+ break;
+ case 2:
+ soft_float_flag = AUTO_BOOLEAN_TRUE;
+ break;
+ default:
+ break;
+ }
+ }
+
+ if (vector_abi == POWERPC_VEC_AUTO && from_elf_exec)
+ {
+ switch (bfd_elf_get_obj_attr_int (info.abfd, OBJ_ATTR_GNU,
+ Tag_GNU_Power_ABI_Vector))
+ {
+ case 1:
+ vector_abi = POWERPC_VEC_GENERIC;
+ break;
+ case 2:
+ vector_abi = POWERPC_VEC_ALTIVEC;
+ break;
+ case 3:
+ vector_abi = POWERPC_VEC_SPE;
+ break;
+ default:
+ break;
+ }
+ }
+#endif
+
+ if (soft_float_flag == AUTO_BOOLEAN_TRUE)
+ soft_float = 1;
+ else if (soft_float_flag == AUTO_BOOLEAN_FALSE)
+ soft_float = 0;
+ else
+ soft_float = !have_fpu;
+
+ /* If we have a hard float binary or setting but no floating point
+ registers, downgrade to soft float anyway. We're still somewhat
+ useful in this scenario. */
+ if (!soft_float && !have_fpu)
+ soft_float = 1;
+
+ /* Similarly for vector registers. */
+ if (vector_abi == POWERPC_VEC_ALTIVEC && !have_altivec)
+ vector_abi = POWERPC_VEC_GENERIC;
+
+ if (vector_abi == POWERPC_VEC_SPE && !have_spe)
+ vector_abi = POWERPC_VEC_GENERIC;
+
+ if (vector_abi == POWERPC_VEC_AUTO)
+ {
+ if (have_altivec)
+ vector_abi = POWERPC_VEC_ALTIVEC;
+ else if (have_spe)
+ vector_abi = POWERPC_VEC_SPE;
+ else
+ vector_abi = POWERPC_VEC_GENERIC;
+ }
+
+ /* Do not limit the vector ABI based on available hardware, since we
+ do not yet know what hardware we'll decide we have. Yuck! FIXME! */
+
/* Find a candidate among extant architectures. */
for (arches = gdbarch_list_lookup_by_info (arches, &info);
arches != NULL;
@@ -3426,6 +3521,10 @@ rs6000_gdbarch_init (struct gdbarch_info
meaningful, because 64-bit CPUs can run in 32-bit mode. So, perform
separate word size check. */
tdep = gdbarch_tdep (arches->gdbarch);
+ if (tdep && tdep->soft_float != soft_float)
+ continue;
+ if (tdep && tdep->vector_abi != vector_abi)
+ continue;
if (tdep && tdep->wordsize == wordsize)
{
if (tdesc_data != NULL)
@@ -3444,6 +3543,8 @@ rs6000_gdbarch_init (struct gdbarch_info
tdep = XCALLOC (1, struct gdbarch_tdep);
tdep->wordsize = wordsize;
+ tdep->soft_float = soft_float;
+ tdep->vector_abi = vector_abi;
gdbarch = gdbarch_alloc (&info, tdep);
@@ -3643,6 +3744,61 @@ rs6000_dump_tdep (struct gdbarch *gdbarc
/* FIXME: Dump gdbarch_tdep. */
}
+/* PowerPC-specific commands. */
+
+static void
+set_powerpc_command (char *args, int from_tty)
+{
+ printf_unfiltered (_("\
+\"set powerpc\" must be followed by an appropriate subcommand.\n"));
+ help_list (setpowerpccmdlist, "set powerpc ", all_commands, gdb_stdout);
+}
+
+static void
+show_powerpc_command (char *args, int from_tty)
+{
+ cmd_show_list (showpowerpccmdlist, from_tty, "");
+}
+
+static void
+powerpc_set_soft_float (char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+ struct gdbarch_info info;
+
+ /* Update the architecture. */
+ gdbarch_info_init (&info);
+ if (!gdbarch_update_p (info))
+ internal_error (__FILE__, __LINE__, "could not update architecture");
+}
+
+static void
+powerpc_set_vector_abi (char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+ struct gdbarch_info info;
+ enum powerpc_vector_abi vector_abi;
+
+ for (vector_abi = POWERPC_VEC_AUTO;
+ vector_abi != POWERPC_VEC_LAST;
+ vector_abi++)
+ if (strcmp (powerpc_vector_abi_string,
+ powerpc_vector_strings[vector_abi]) == 0)
+ {
+ powerpc_vector_abi_global = vector_abi;
+ break;
+ }
+
+ if (vector_abi == POWERPC_VEC_LAST)
+ internal_error (__FILE__, __LINE__, _("Invalid vector ABI accepted: %s."),
+ powerpc_vector_abi_string);
+
+ /* Update the architecture. */
+ gdbarch_info_init (&info);
+ if (!gdbarch_update_p (info))
+ internal_error (__FILE__, __LINE__, "could not update architecture");
+}
+
/* Initialization code. */
extern initialize_file_ftype _initialize_rs6000_tdep; /* -Wmissing-prototypes */
@@ -3668,4 +3824,30 @@ _initialize_rs6000_tdep (void)
initialize_tdesc_powerpc_860 ();
initialize_tdesc_powerpc_e500 ();
initialize_tdesc_rs6000 ();
+
+ /* Add root prefix command for all "set powerpc"/"show powerpc"
+ commands. */
+ add_prefix_cmd ("powerpc", no_class, set_powerpc_command,
+ _("Various PowerPC-specific commands."),
+ &setpowerpccmdlist, "set powerpc ", 0, &setlist);
+
+ add_prefix_cmd ("powerpc", no_class, show_powerpc_command,
+ _("Various PowerPC-specific commands."),
+ &showpowerpccmdlist, "show powerpc ", 0, &showlist);
+
+ /* Add a command to allow the user to force the ABI. */
+ add_setshow_auto_boolean_cmd ("soft-float", class_support,
+ &powerpc_soft_float_global,
+ _("Set whether to use a soft-float ABI."),
+ _("Show whether to use a soft-float ABI."),
+ NULL,
+ powerpc_set_soft_float, NULL,
+ &setpowerpccmdlist, &showpowerpccmdlist);
+
+ add_setshow_enum_cmd ("vector-abi", class_support, powerpc_vector_strings,
+ &powerpc_vector_abi_string,
+ _("Set the vector ABI."),
+ _("Show the vector ABI."),
+ NULL, powerpc_set_vector_abi, NULL,
+ &setpowerpccmdlist, &showpowerpccmdlist);
}
Index: doc/gdb.texinfo
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.440
diff -u -p -r1.440 gdb.texinfo
--- doc/gdb.texinfo 24 Oct 2007 21:05:36 -0000 1.440
+++ doc/gdb.texinfo 30 Oct 2007 15:06:46 -0000
@@ -14937,7 +14937,25 @@ Set suspend trace mode.
@node PowerPC
@subsection PowerPC
+@value{GDBN} provides the following PowerPC-specific commands:
+
@table @code
+@kindex set powerpc
+@item set powerpc soft-float
+@itemx show powerpc soft-float
+Force @value{GDBN} to use (or not use) a software floating point calling
+convention. By default, @value{GDBN} selects the calling convention based
+on the selected architecture and the provided executable file.
+
+@item set powerpc vector-abi
+@itemx show powerpc vector-abi
+Force @value{GDBN} to use the specified calling convention for vector
+arguments and return values. The valid options are @samp{auto};
+@samp{generic}, to avoid vector registers even if they are present;
+@samp{altivec}, to use AltiVec registers; and @samp{spe} to use SPE
+registers. By default, @value{GDBN} selects the calling convention
+based on the selected architecture and the provided executable file.
+
@kindex target dink32
@item target dink32 @var{dev}
DINK32 ROM monitor.
@@ -14955,7 +14973,7 @@ SDS monitor, running on a PowerPC board
@cindex SDS protocol
The following commands specific to the SDS protocol are supported
-by@value{GDBN}:
+by @value{GDBN}:
@table @code
@item set sdstimeout @var{nsec}
Index: testsuite/gdb.arch/altivec-abi.exp
===================================================================
RCS file: /scratch/gcc/repos/src/src/gdb/testsuite/gdb.arch/altivec-abi.exp,v
retrieving revision 1.12
diff -u -p -r1.12 altivec-abi.exp
--- testsuite/gdb.arch/altivec-abi.exp 21 Oct 2007 12:28:00 -0000 1.12
+++ testsuite/gdb.arch/altivec-abi.exp 30 Oct 2007 19:07:28 -0000
@@ -13,9 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
-# Please email any bugs, comments, and/or additions to this file to:
-# bug-gdb@prep.ai.mit.edu
-#
# Tests for Powerpc AltiVec ABI
@@ -28,9 +25,6 @@ if $tracelevel then {
# This file uses altivec-abi.c for input.
#
-set prms_id 0
-set bug_id 0
-
if {![istarget "powerpc*"] || [skip_altivec_tests]} then {
verbose "Skipping altivec abi tests."
verbose -log "Skipping altivec abi tests."
@@ -41,88 +35,124 @@ set testfile "altivec-abi"
set binfile ${objdir}/${subdir}/${testfile}
set srcfile ${testfile}.c
-set compile_flags {debug nowarnings}
if [get_compiler_info $binfile] {
warning "get_compiler failed"
return -1
}
+proc altivec_abi_tests { extra_flags force_abi } {
+ global testfile binfile srcfile srcdir subdir
+ global gdb_prompt
+
+ set compile_flags "debug nowarnings $extra_flags"
+
+ if { [gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile} executable $compile_flags] != "" } {
+ untested altivec-abi.exp
+ return -1
+ }
+
+ if { "$force_abi" == "auto" } {
+ # If the toolchain does not record attributes, skip auto-ABI tests.
+ set readelf_program [transform readelf]
+ set result [catch "exec $readelf_program -A $binfile" output]
+
+ if {$result == 0 && ![regexp Tag_GNU_Power_ABI_Vector $output]} {
+ untested "ABI not marked"
+ return
+ }
+ }
+
+ gdb_exit
+ gdb_start
+ gdb_reinitialize_dir $srcdir/$subdir
+ gdb_load ${binfile}
+
+ # Run to `main' where we begin our tests.
+ if ![runto_main] then {
+ untested altivec-abi.exp
+ return -1
+ }
+
+ gdb_test "set powerpc vector-abi $force_abi"
+
+ gdb_test "b marker" "Breakpoint 2 at.*file.*altivec-abi.c, line \[0-9\]+." "break marker"
+ gdb_test "continue" "Breakpoint 2.*marker.*altivec-abi.c.*" "continue to marker"
+ gdb_test "finish" "Run till exit from .0.*marker.*at.*altivec-abi.c.*main \\(\\) at.*altivec-abi.c.*result = vec_func \\(vshort,.*goes in v2.*" "back to main (1)"
+
+ # now all the arguments of vec_fun are initialized
+
+ set pattern "vec_func .vshort_f=.111, 222, 333, 444, 555, 666, 777, 888., vushort_f=.100, 200, 300, 400, 500, 600, 700, 800., vint_f=.-10, -20, -30, -40., vuint_f=.1111, 2222, 3333, 4444., vchar_f=.abcdefghilmnopqr., vuchar_f=.ABCDEFGHILMNOPQR., vfloat_f=.1.25, 3.75, 5.5, 1.25., x_f=.1, 2, 3, 4, 5, 6, 7, 8., y_f=.12, 22, 32, 42., a_f=.vector of chars.., b_f=.5.5, 4.5, 3.75, 2.25., c_f=.1.25, 3.5, 5.5, 7.75., intv_on_stack_f=.12, 34, 56, 78.."
+
+ set pattern1 $pattern
+ append pattern1 " at.*altivec-abi.c.*vint_res = vec_add.*vint_f, intv_on_stack_f.;"
+
+ # Now let's call the function. This function has > 12 args,
+ # the last one will go on the stack.
+ set msg "call inferior function with vectors (1)"
+ gdb_test "p vec_func(vshort,vushort,vint,vuint,vchar,vuchar,vfloat,x,y,a,b,c,intv_on_stack)" \
+ ".\[0-9\]+ = .2, 2, 2, 2." "call inferior function with vectors (1)"
+
+ # Let's call the function again with dummy arguments. This is to clean
+ # up the contents of the vector registers before the next call.
+ gdb_test "p vec_func(vshort_d,vushort_d,vint_d,vuint_d,vchar_d,vuchar_d,vfloat_d,x_d,y_d,a_d,b_d,c_d,intv_on_stack_d)" \
+ ".\[0-9\]+ = .0, 0, 0, 0." "call inferior function with vectors (2)"
+
+ # Let's step into the function, to see if the args are printed correctly.
+ gdb_test "step" \
+ $pattern1 \
+ "step into vec_fun"
+
+ set pattern2 $pattern
+ append pattern2 " at.*altivec-abi.c.*main.*result = vec_func .vshort,.*goes in v2.*Value returned is.*= .2, 2, 2, 2."
+
+ # Let's see if the result is returned correctly.
+ gdb_test "finish" "Run till exit from .0.*$pattern2" \
+ "vector value returned correctly"
+
+ # can we print the args correctly for this function?
+ gdb_test "break struct_of_vector_func" "" ""
+
+ set pattern "struct_of_vector_func .vector_struct=.vshort1 = .1, 2, 3, 4, 5, 6, 7, 8., vshort2 = .11, 12, 13, 14, 15, 16, 17, 18., vshort3 = .21, 22, 23, 24, 25, 26, 27, 28., vshort4 = .31, 32, 33, 34, 35, 36, 37, 38... at.*altivec-abi.c.*"
+
+ gdb_test "continue" \
+ "Breakpoint 3, $pattern.*vector_struct.vshort1 = vec_add .vector_struct.vshort1, vector_struct.vshort2.;" \
+ "continue to struct_of_vector_func"
+
+ gdb_test "finish" \
+ "Run till exit from .0 $pattern\[ \r\n\]+main.*altivec-abi.c.*array_of_vector_func.*" \
+ "back to main (2)"
+
+ gdb_test "step" "" "step into array_of_vector_func"
+ gdb_test "p matrix\[0\]" ".*= .1, 2, 3, 4, 5, 6, 7, 8." "print first vector"
+ gdb_test "p matrix\[1\]" ".*= .11, 12, 13, 14, 15, 16, 17, 18." "print second vector"
+ gdb_test "p matrix\[2\]" ".*= .21, 22, 23, 24, 25, 26, 27, 28." "print third vector"
+ gdb_test "p matrix\[3\]" ".*= .31, 32, 33, 34, 35, 36, 37, 38." "print fourth vector"
+}
+
if [test_compiler_info gcc*] {
- set compile_flags "$compile_flags additional_flags=-maltivec additional_flags=-mabi=altivec"
+ set saved_prefix $pf_prefix
+
+ set pf_prefix "${saved_prefix} default ABI, auto:"
+ altivec_abi_tests "additional_flags=-maltivec" "auto"
+
+ # On GNU/Linux, we can mix -mabi=no-altivec and -mabi=altivec.
+ # So test some combinations.
+ if { [istarget "powerpc*-linux*"] } {
+ set binfile ${objdir}/${subdir}/${testfile}-ge-ge
+ set pf_prefix "${saved_prefix} generic ABI, forced:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=no-altivec" "generic"
+
+ set binfile ${objdir}/${subdir}/${testfile}-av-av
+ set pf_prefix "${saved_prefix} AltiVec ABI, forced:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=altivec" "altivec"
+
+ set binfile ${objdir}/${subdir}/${testfile}-av-auto
+ set pf_prefix "${saved_prefix} AltiVec ABI, auto:"
+ altivec_abi_tests "additional_flags=-maltivec additional_flags=-mabi=altivec" "auto"
+ }
} elseif [test_compiler_info xlc*] {
- set compile_flags "$compile_flags additional_flags=-qaltivec"
+ altivec_abi_tests "additional_flags=-qaltivec" "auto"
} else {
warning "unknown compiler"
return -1
}
-
-if { [gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile} executable $compile_flags] != "" } {
- untested altivec-abi.exp
- return -1
-}
-
-gdb_start
-gdb_reinitialize_dir $srcdir/$subdir
-gdb_load ${binfile}
-
-#
-# Run to `main' where we begin our tests.
-#
-
-if ![runto_main] then {
- gdb_suppress_tests
-}
-
-gdb_test "b marker" "Breakpoint 2 at.*file.*altivec-abi.c, line \[0-9\]+." "break marker"
-gdb_test "continue" "Breakpoint 2.*marker.*altivec-abi.c.*" "continue to marker"
-gdb_test "finish" "Run till exit from .0.*marker.*at.*altivec-abi.c.*main \\(\\) at.*altivec-abi.c.*result = vec_func \\(vshort,.*goes in v2.*" "back to main (1)"
-
-# now all the arguments of vec_fun are initialized
-
-set pattern "vec_func .vshort_f=.111, 222, 333, 444, 555, 666, 777, 888., vushort_f=.100, 200, 300, 400, 500, 600, 700, 800., vint_f=.-10, -20, -30, -40., vuint_f=.1111, 2222, 3333, 4444., vchar_f=.abcdefghilmnopqr., vuchar_f=.ABCDEFGHILMNOPQR., vfloat_f=.1.25, 3.75, 5.5, 1.25., x_f=.1, 2, 3, 4, 5, 6, 7, 8., y_f=.12, 22, 32, 42., a_f=.vector of chars.., b_f=.5.5, 4.5, 3.75, 2.25., c_f=.1.25, 3.5, 5.5, 7.75., intv_on_stack_f=.12, 34, 56, 78.."
-
-set pattern1 $pattern
-append pattern1 " at.*altivec-abi.c.*vint_res = vec_add.*vint_f, intv_on_stack_f.;"
-
-# Now let's call the function. This function has > 12 args,
-# the last one will go on the stack.
-gdb_test "p vec_func(vshort,vushort,vint,vuint,vchar,vuchar,vfloat,x,y,a,b,c,intv_on_stack)" \
-".\[0-9\]+ = .2, 2, 2, 2." "call inferior function with vectors (1) "
-
-# Let's call the function again with dummy arguments. This is to clean
-# up the contents of the vector registers before the next call.
-gdb_test "p vec_func(vshort_d,vushort_d,vint_d,vuint_d,vchar_d,vuchar_d,vfloat_d,x_d,y_d,a_d,b_d,c_d,intv_on_stack_d)" \
-".\[0-9\]+ = .0, 0, 0, 0." "call inferior function with vectors (2) "
-
-# Let's step into the function, to see if the args are printed correctly.
-gdb_test "step" \
- $pattern1 \
- "step into vec_fun"
-
-set pattern2 $pattern
-append pattern2 " at.*altivec-abi.c.*main.*result = vec_func .vshort,.*goes in v2.*Value returned is.*= .2, 2, 2, 2."
-
-# Let's see if the result is returned correctly.
-gdb_test "finish" \
- "Run till exit from .0.*$pattern2" \
- "vector value returned correctly"
-
-# can we print the args correctly for this function?
-gdb_test "break struct_of_vector_func" "" ""
-
-set pattern "struct_of_vector_func .vector_struct=.vshort1 = .1, 2, 3, 4, 5, 6, 7, 8., vshort2 = .11, 12, 13, 14, 15, 16, 17, 18., vshort3 = .21, 22, 23, 24, 25, 26, 27, 28., vshort4 = .31, 32, 33, 34, 35, 36, 37, 38... at.*altivec-abi.c.*"
-
-gdb_test "continue" \
- "Breakpoint 3, $pattern.*vector_struct.vshort1 = vec_add .vector_struct.vshort1, vector_struct.vshort2.;" \
- "continue to struct_of_vector_func"
-
-gdb_test "finish" \
- "Run till exit from .0 $pattern\[ \r\n\]+main.*altivec-abi.c.*array_of_vector_func.*" \
- "back to main (2)"
-
-gdb_test "step" "" "step into array_of_vector_func"
-gdb_test "p matrix\[0\]" ".*= .1, 2, 3, 4, 5, 6, 7, 8." "print first vector"
-gdb_test "p matrix\[1\]" ".*= .11, 12, 13, 14, 15, 16, 17, 18." "print second vector"
-gdb_test "p matrix\[2\]" ".*= .21, 22, 23, 24, 25, 26, 27, 28." "print third vector"
-gdb_test "p matrix\[3\]" ".*= .31, 32, 33, 34, 35, 36, 37, 38." "print fourth vector"
-
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [rfc] PowerPC ABI detection and overrides
2007-10-30 20:12 ` Daniel Jacobowitz
@ 2007-10-30 21:12 ` Ulrich Weigand
0 siblings, 0 replies; 15+ messages in thread
From: Ulrich Weigand @ 2007-10-30 21:12 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> Here's what I checked in. This skips some of the tests when using ELF
> without ABI markings, but still runs enough to be useful - the tests
> fail in a way that's hard to XFAIL, since the generic ABI uses
> pass by reference so we end up with bad pointers.
This looks fine to me; I've tested on a native powerpc-linux (with an old
toolchain), without any FAILs.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2007-10-30 20:58 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-21 13:05 [commit] Use -mabi=altivec for AltiVec tests Ulrich Weigand
2007-10-21 18:08 ` Daniel Jacobowitz
2007-10-21 19:37 ` Ulrich Weigand
2007-10-24 20:47 ` Daniel Jacobowitz
2007-10-29 18:04 ` Ulrich Weigand
2007-10-29 18:06 ` Daniel Jacobowitz
2007-10-29 18:32 ` Ulrich Weigand
2007-10-25 20:32 ` [rfc] PowerPC ABI detection and overrides Daniel Jacobowitz
2007-10-29 18:27 ` Ulrich Weigand
2007-10-29 18:38 ` Daniel Jacobowitz
2007-10-29 19:02 ` Ulrich Weigand
2007-10-29 19:16 ` Daniel Jacobowitz
2007-10-29 19:27 ` Ulrich Weigand
2007-10-30 20:12 ` Daniel Jacobowitz
2007-10-30 21:12 ` Ulrich Weigand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox