From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6682 invoked by alias); 2 Dec 2006 16:27:21 -0000 Received: (qmail 6672 invoked by uid 22791); 2 Dec 2006 16:27:20 -0000 X-Spam-Check-By: sourceware.org Received: from wx-out-0506.google.com (HELO wx-out-0506.google.com) (66.249.82.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Dec 2006 16:27:14 +0000 Received: by wx-out-0506.google.com with SMTP id h26so3446590wxd for ; Sat, 02 Dec 2006 08:27:13 -0800 (PST) Received: by 10.70.87.11 with SMTP id k11mr11085922wxb.1165076832887; Sat, 02 Dec 2006 08:27:12 -0800 (PST) Received: by 10.70.12.7 with HTTP; Sat, 2 Dec 2006 08:27:12 -0800 (PST) Message-ID: Date: Sat, 02 Dec 2006 16:27:00 -0000 From: "Rob Quill" To: "Michael Snyder" Subject: Re: Single stepping and threads Cc: "Joel Brobecker" , gdb@sourceware.org In-Reply-To: <1164929776.14460.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061129052942.GA16029@nevyn.them.org> <20061129055915.GM9968@adacore.com> <20061129132535.GA28834@nevyn.them.org> <20061129163844.GN9968@adacore.com> <1164929776.14460.36.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00002.txt.bz2 On 30/11/06, Michael Snyder wrote: > On Wed, 2006-11-29 at 08:38 -0800, Joel Brobecker wrote: > > > > I would say yes. A step should be a few instructions, while stepping > > > > over a call is potentially a much larger number of instructions. > > > > As a result, stepping over without letting the other threads go would > > > > more likely cause a lock. > > > > > > I think you mean "no" then? > > > > Oops, sorry, I meant "no". > > > > One of my coworkers expressed his opinion as follow: > > > > << > > I would find it confusing if "step" and "next" behave differently with > > respect to threads, because they seem like basically the same thing. > > "Next is just like step, except that it goes over calls" seems simple to > > me. "Next is just like step, except that it goes over calls, and has > > some subtle difference regarding threads" seems more complicated to me. > > > > So I would suggest leaving the default as "off", or else changing it > > to "on". > > Default on would be a disaster -- most threaded programs would > not behave even remotely the same under the debugger as they would > solo. > > In fact, many would deadlock almost immediately. I have a question regarding this. In concurrent programming (as we were tuaght it), the principle was that the interleaving of instructions from threads was random. So, if "on" were the default, and a few steps were done in GDB, in fact, as many as it took to deadlock the program, surely it is possible (although, however unlikely) that when the program is run without GDB that the interleaving is the same as that forced by GDB, and the code would deadlock. Thus making the code bad, rather than the debugger. What I'm trying to say is that it was my understanding that when doing concurent programming the interleaving was random and that for the program to be "corrent" it should not deadlock under any possible interleaving. I fail to see how stopping all threads and just going forward with one should stop "correct" code from executiong properly. Rob > > >