From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: New function for gdb-ui.el? Date: Wed, 26 Oct 2005 21:58:41 +1300 Message-ID: <17247.17729.366833.431749@kahikatea.snap.net.nz> References: <17243.21638.138477.436126@kahikatea.snap.net.nz> <17244.34246.93773.562211@kahikatea.snap.net.nz> <17245.17271.523511.307415@kahikatea.snap.net.nz> <17246.47395.926373.263704@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1130322365 25517 80.91.229.2 (26 Oct 2005 10:26:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2005 10:26:05 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, ich@frank-schmitt.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 26 12:25:57 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EUiRx-0002ld-Q4 for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2005 12:24:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUiRv-0001y7-LF for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2005 06:24:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EUh8D-00009j-57 for emacs-devel@gnu.org; Wed, 26 Oct 2005 04:59:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EUh7A-00086A-Iy for emacs-devel@gnu.org; Wed, 26 Oct 2005 04:58:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUh6s-00080P-Vm for emacs-devel@gnu.org; Wed, 26 Oct 2005 04:58:16 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EUh6o-0002ab-JR; Wed, 26 Oct 2005 04:58:11 -0400 Original-Received: from kahikatea.snap.net.nz (p85-tnt2.snap.net.nz [202.124.108.85]) by viper.snap.net.nz (Postfix) with ESMTP id 8589E731183; Wed, 26 Oct 2005 21:57:58 +1300 (NZDT) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 3696E8402; Wed, 26 Oct 2005 21:58:42 +1300 (NZDT) Original-To: Eli Zaretskii In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.23 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44893 Archived-At: > > The manual says: > > > > GDB> Continue running your program until either the specified location > > GDB> is reached, or the current stack frame returns. > > > > (actually, it should say *selected* stack frame returns) > > I don't think ``selected'' is more accurate or more clear in this > context than ``current''. My understanding is that "current frame" refers to the innermost frame where execution has stopped. The "selected frame" refers to the frame that GDB is looking at and can be changed with the "up" and "down" commands. If I stop in a frame, I can use "up" to go up a frame and then "until" to advance along that "selected frame" even though execution had stopped in the frame below. Unfortunately "current frame" has some ambiguity and the GDB manual seems to mix its meaning. > The latest version of the manual has this clarification: > > The specified location is actually reached only if it is in the > current frame. I think it should say: The specified location is actually reached only if it is in the same frame. > > > > But there is an exception: when a function in one file is > > > > inlined in another. In that case, shouldn't this command work? > > > > > > If I try it, it doesn't seem to work. Even if it, I'm not sure how we > > > would make use of it. > > > > > > If it doesn't work, maybe that is a flaw in GDB. It OUGHT to be > > > possible to proceed to a specific line in the code another function > > > that was inlined into this function. > > > > > > Would you like to raise that is with bug-gdb and cc me? > > > > The problem is that the documentation just talks about being able to skip > > over recursive functions and doesn't mention inline functions. So I'm > > not sure that they would see it as a bug. > > I'd suggest to craft a simple test case with inlined function and ask > the question on the GDB mailing list. I'd expect `until' to stop in > an inlined function; the fact that the manual doesn't say anything > about this might just be a documentation bug. I don't think I understand the issues. I thought if I used the keyword inline e.g "inline int mysquare (int x)", I would get an inline function. Perhaps thats not the case because I can set a breakpoint, stop there and see mysquare in the stack. If I use -O2 or -O3 (gcc 3.4.4) then I can't stop there (because its inlined?). So how can "until" possibly proceed to there? Nick