From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-21861-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 4537 invoked by alias); 15 Jan 2003 19:39:31 -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 4528 invoked from network); 15 Jan 2003 19:39:30 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 15 Jan 2003 19:39:30 -0000
Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0FJBAB02241
	for <gdb-patches@sources.redhat.com>; Wed, 15 Jan 2003 14:11:10 -0500
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 h0FJdSn02939;
	Wed, 15 Jan 2003 14:39:29 -0500
Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h0FJdSE32290;
	Wed, 15 Jan 2003 11:39:28 -0800
Message-ID: <3E25B8F0.6690551A@redhat.com>
Date: Wed, 15 Jan 2003 19:39:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Cagney <ac131313@redhat.com>
CC: gdb-patches@sources.redhat.com
Subject: Re: threads and target-function-calls
References: <3E1B7829.6B6E8BAF@redhat.com> <3E1C4F29.2070003@redhat.com> <3E1CC6AA.465581D@redhat.com> <3E1CC8C4.600442A9@redhat.com> <3E1CCAD1.6030009@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-01/txt/msg00576.txt.bz2

Andrew Cagney wrote:
> 
> > Michael Snyder wrote:
> >
> >>
> >> Andrew Cagney wrote:
> >
> >> >
> >
> >> > > Hey folks,
> >> > >
> >> > > Did you know that (at least on x86 linux), if you have a multi-thread
> >> > > program and you execute a target function call, all the threads get to
> >> > > run?  Doesn't that seem like a bad thing?  Wouldn't we really rather
> >> > > only run the thread that is executing the target function call?
> >
> >> >
> >> > Ha!  That's just the start.  Doing nested inferior function calls on
> >> > alternative threads scrables the dummy frame cache:
> >> > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=468
> >
> >>
> >> But... that's just sick.   ;-(
> >> Wait -- you can't do that.  It isn't meaningful to change threads
> >> and then continue/whatever.  It assumes gdb has more control over
> >> scheduling than it actually has.
> >
> >
> > Oh, I think I misunderstood.  You have in mind this:
> >       (gdb) print foo()
> >       [switching thread to xyz]
> >       Breakpoint 2 in foo ()
> >       (gdb) print bar()
> >
> > not this:
> >       (gdb) print foo ()
> >       breakpoint 2 in foo()
> >       (gdb) thread xyz
> >       (gdb) print bar()
> >
> > right?
> 
> Either.  

OK, well, the second should not be a concern, because
prepare_to_proceed is supposed to switch us back to the
event thread before we resume.