Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: Hui Zhu <teawater@gmail.com>,
	  "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: i386 floating point test case integration with gdb.reverse test-suite
Date: Sun, 16 Aug 2009 21:44:00 -0000	[thread overview]
Message-ID: <4A887C5D.6040200@vmware.com> (raw)
In-Reply-To: <614639.81774.qm@web112505.mail.gq1.yahoo.com>

paawan oza wrote:
> Hi Michael,
> 
> please find the test case patch attached. Mainly the patch is intending to test floating point patch which I have submitted earlier.
> 
> tests are as follws.
> 
> 1) first test tests basic testing of FPU stack (st0-st7) and its restoring while reverse execution,
> 2) second test is testing FPU environment specially fstatus and ftag register.
> 
> please find the patch attached. (I am not pasting patch in email text because of space and tab issue)
> 
> please review and let me know your comments.
> 
> Regards,
> Oza.

These are very good!  Congratulations on getting the hang of dejagnu so 
quickly.

A few pretty minor suggestions...

1) There are some tests that look like this:
    gdb_test "info register st2" "st2 *1.*"
and some that look like this:
    gdb_test "info register st1" "st1 *1\t.*"
(with a tab in the regular expression).

I like the ones with the tab better -- its more exact, and it
makes certain that the value is really "1", and not eg. "1.1".
Could you make them all like that?  Just the single-digit values.
I'm not worried about the multi-digit ones.

2) The file names should reflect the Intel architecture, since
eventually we will have process record for other architectures.
In fact, maybe these tests should go in gdb.arch instead of in
gdb.reverse, since all the other tests in gdb.reverse are
architecture independent.

How about testsuite/gdb.arch/i387-stack-reverse.exp, etc?

3) I'm not an Intel expert, but you had mentioned a few
other registers in an earlier post, namely:
   fstat
   ftag
   fiseg
   fioff
   foseg
   fooff
   fop

Are all of those handled now?  If so, could we include them in the test?

Thanks again for your hard work and patience.
Michael


  parent reply	other threads:[~2009-08-16 21:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 13:43 paawan oza
2009-08-09 22:55 ` Michael Snyder
2009-08-16 21:44 ` Michael Snyder [this message]
2009-08-16 22:57   ` Michael Snyder
2009-08-17 17:47   ` paawan oza
2009-08-21 22:15 paawan oza
2009-08-23  3:31 ` Michael Snyder
2009-12-04  3:16   ` paawan oza
2009-12-10  7:52 ` Hui Zhu
2009-12-04  3:39 paawan oza
2009-12-04 19:03 ` Michael Snyder
2009-12-08  5:22   ` Hui Zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A887C5D.6040200@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb-patches@sourceware.org \
    --cc=paawan1982@yahoo.com \
    --cc=teawater@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox