From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-35193-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 9319 invoked by alias); 12 Aug 2004 00:26:54 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 9159 invoked from network); 12 Aug 2004 00:26:52 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 12 Aug 2004 00:26:52 -0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7C0Qpe1010440
	for <gdb-patches@sources.redhat.com>; Wed, 11 Aug 2004 20:26:52 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7C0QjX16449;
	Wed, 11 Aug 2004 20:26:45 -0400
Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i7C0QTV01503;
	Wed, 11 Aug 2004 17:26:39 -0700
Message-ID: <411AB934.5070602@redhat.com>
Date: Thu, 12 Aug 2004 00:26:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.2) Gecko/20040301
MIME-Version: 1.0
To: Manoj Iyer <manjo@austin.ibm.com>
CC: Michael Chastain <mec.gnu@mindspring.com>, gdb-patches@sources.redhat.com,
        gilliam@us.ibm.com
Subject: Re: [RFC] New thread testcase.
References: <4117F82B.nail1N111PN0T@mindspring.com> <Pine.LNX.4.58.0408091818400.18782@lazy>
In-Reply-To: <Pine.LNX.4.58.0408091818400.18782@lazy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-08/txt/msg00424.txt.bz2

Hello Manoj,

> #
> # step through the thread function.
> #
> send_gdb "step\n"
> gdb_expect {
>     -re "39.*sprintf.* .*\r\n$gdb_prompt $" {
>         pass "step to next instruction in tf";
>     }
>     -re ".*$gdb_prompt $" {
>         fail "step to next instruction in tf";
>         return 1;
>     }
>     timeout {
>         fail "step to next instruction in tf (timeout)";
>         return 1;
>     }
> }

This will probably work as written, but it hints at a faulty
assumption that might lead it to break if the test is modified
in the future.

When you say "step", you allow the opportunity for the inferior
to switch thread contexts.  At present there are only two threads,
and no other breakpoints exist that might be hit, but if that were
not the case, the next stop event could be at another breakpoint,
in another thread.  This would not be a bug, and should not cause
a fail.  It's expected behavior.

I suppose this could be addressed with a comment, warning the
future maintainer to take it into consideration if more threads
or breakpoints are added.

But like Andrew, I would also like to know what the expected
failure is -- what used to happen before the kernel bug was
fixed?  A comment explaining that would be welcome too.

Michael Snyder