From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37544 invoked by alias); 19 Mar 2019 20:44:52 -0000 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 Received: (qmail 37535 invoked by uid 89); 19 Mar 2019 20:44:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:87mulqx, H*f:sk:87mulqx, tail-recursive, tailrecursive X-HELO: mail-io1-f44.google.com Received: from mail-io1-f44.google.com (HELO mail-io1-f44.google.com) (209.85.166.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Mar 2019 20:44:50 +0000 Received: by mail-io1-f44.google.com with SMTP id n11so19280654ioh.1 for ; Tue, 19 Mar 2019 13:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f/snKWAw+pWOE1JrNQ+uzyvovY4tUsMVDmY2C9YG0Uk=; b=Tgj+K357hrKAj6zTiEOm58uOvL+NSdjkc7sxEW3B/ypORVxiUDLNYnQFgUbnLtKlFK EaIpk0N3SoEKp2lG++C8ukoBQy2cN5aq115AEO/TdJMqzQauBcwq5EgtIiK+SQ4yP1Af z2slACDCdD4R2TvfjXWIc1LZOyAVcP8R+UIwUdDCzFXdCPUw83Ib72UXYuSPCLTLoQ0h c/JrSGcVaWjpSLskmqxYrR9VRbIod/xrWFf/x+7bgsS+7t2wE5ckr0922rxMA9VuJ7QH fGQp+Rd7F//btc74/HTFIFTnx4+heaenirjdnDcFSLVMNehcNkr+9chN6ETxDUgAcSMu XjNQ== MIME-Version: 1.0 References: <87va0i74jq.fsf@igel.home> <431d242053ca491be67a21d0d95b71a4@polymtl.ca> <87mulqx44z.fsf@tromey.com> In-Reply-To: <87mulqx44z.fsf@tromey.com> From: Justin Paston-Cooper Date: Tue, 19 Mar 2019 20:44:00 -0000 Message-ID: Subject: Re: Command to break before exiting stack frame? To: Tom Tromey Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-03/txt/msg00059.txt.bz2 Tom> It seems to me that a tail call means there just isn't a return value Tom> from the calling function, only from the callee, because the caller Tom> doesn't even really have a separate return statement. That makes sense actually. Although I would hope that the break on exit command would break after any tail-recursive call exits. Tom> On the whole I think it would be better to start with the compiler. If Tom> it emits epilogue markers, then the gdb work is not difficult. Thanks for the tips. I've sent a message to the gcc mailing list. On Tue, 19 Mar 2019 at 15:42, Tom Tromey wrote: > > Justin> Given its documentation, I would have expected the "finish" command to > Justin> print the returned value at each tail call. It turns out that it > Justin> prints the returned value only for the f(0) call. I would similarly > Justin> expect a "break on exit" command to break on the exit of the frame in > Justin> which it is called even if a tail-recursion occurs. Is there a reason > Justin> that it doesn't? > > It seems to me that a tail call means there just isn't a return value > from the calling function, only from the callee, because the caller > doesn't even really have a separate return statement. > > I suppose, though, if it is like inlining, then this text from the > manual also applies: > > * GDB cannot locate the return value of inlined calls after using the > 'finish' command. This is a limitation of compiler-generated > debugging information; after 'finish', you can step to the next > line and print a variable where your program stored the return > value. > > Justin> On the actual implementation of this command: Is the implementation of > Justin> such a feature feasible? If so, how much work would it take? > > For the compiler, I couldn't say. For gdb, doing it without help from > the compiler seems difficult, as you'd probably have to write an > instruction decoder. gdb already has these for some architectures > (various kinds, actually, for different things), but probably not in a > useful form. > > On the whole I think it would be better to start with the compiler. If > it emits epilogue markers, then the gdb work is not difficult. > > Tom