This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] add ppc testcase to test fpscr
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Tue, 02 Sep 2008 20:31:50 -0300
- Subject: Re: [rfc] add ppc testcase to test fpscr
- References: <1219360611.8989.6.camel@localhost.localdomain> <20080821233115.GA1239@caradoc.them.org> <1219362081.29526.2.camel@localhost.localdomain> <20080822024659.GA12951@caradoc.them.org> <1219428669.8167.2.camel@localhost.localdomain> <20080902213949.GH3774@adacore.com>
El mar, 02-09-2008 a las 23:39 +0200, Joel Brobecker escribiÃ:
> I didn't see anyone actually review the patch so I took a look.
Thanks!
> Looks OK to me, but I'm really wonderng why you added a '\r' at
> the end of the expected output in our gdb_test calls.
That was the closest I could think of to an EOL marker. Using '$' is not
an option, I believe.
> For instance:
>
> > +gdb_test "print \$fpscr" " = 0\r" "FPSCR is all zeroes"
>
> Usually, I just do:
>
> gdb_test "print \$fpscr" " = 0" "FPSCR is all zeroes"
>
> Is there something specific that you are trying to do with the '\r'?
In the instance you show I agree it's not very useful, but here:
> > +gdb_test "print/t \$fpscr" " = 10100000001000010001000000000000\r" "FPSCR for invalid operation"
I want to be sure I am testing the lower 32-bits of the FPSCR. For the
moment, this is meaningless since the FPSCR is assumed to always be 32
bits wide in GDB (also, the " = " in the beginning of the pattern
doesn't help). But the FPSCR is actually 64 bits wide starting with
Power ISA 2.05 (only Power6 at the moment). That's what I'm playing with
which prompted me to write this testcase, actually.
> > +#include <stdio.h>
>
> Is the use of stdio necessary in this case. If you can do without,
> then this would allow us to run this testcase in the bareboard case
> (powerpc-elf). Not strictly necessary, but nice to have...
I added the printf calls just to make sure GCC doesn't make the 'result'
variable vanish. Maybe that's not necessary, since the asm blocks
mention result as an output variable? Or maybe GCC would also nuke the
asm blocks instead, seeing that they serve no useful purpose if 'result'
is also not used? I don't know.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center