From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66042 invoked by alias); 17 Mar 2019 13:59:03 -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 66033 invoked by uid 89); 17 Mar 2019 13:59:03 -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=replied, H*i:sk:431d242, H*f:sk:431d242, HX-Languages-Length:2305 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; Sun, 17 Mar 2019 13:59:02 +0000 Received: by mail-io1-f44.google.com with SMTP id b6so12244824iog.0 for ; Sun, 17 Mar 2019 06:59:01 -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:content-transfer-encoding; bh=KOCT4PtLLjMOIEL/T7O8YHpzC5FKoBrllM7KyTSrhjM=; b=gWaTQFTp8Q89nqwodD+Ncir/iXZltAFa8mr/iMYoHvZ5BYJXueI8Kz50bBrTFIzTIG PbcpdQaV+to2w0sni/1FtSW6YnXJMRIzf1tIaV7ELVEu0l4W0A5+gXPOk2ykix28bQEx RpcrbVLeQeXCGt+t6FMOs9srmz/GodptmMplVDk+j+cO/pH4InZ6b6wvZDioav5vVCiS McW0iVB0KHLhotcnkXnbrrNzuc94s25/wCtWFQuXVWxDwkOFZX0+mgOvFwKAeCKLKAMb greKoK7VwXOx7Jygf4IKgvgvOUq/htCCJgXtC+IOQ6Lgwr2+d61FgwnJtnoNuX4pe8GA d7PQ== MIME-Version: 1.0 References: <87va0i74jq.fsf@igel.home> <431d242053ca491be67a21d0d95b71a4@polymtl.ca> In-Reply-To: <431d242053ca491be67a21d0d95b71a4@polymtl.ca> From: Justin Paston-Cooper Date: Sun, 17 Mar 2019 13:59:00 -0000 Message-ID: Subject: Re: Command to break before exiting stack frame? To: Simon Marchi Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-03/txt/msg00049.txt.bz2 I accidentally replied to Andreas's email without CCing the list. Simon has addressed the jump issue. Does gcc emit jump tables when optimisation options are not enabled anyway? On tail calls: I tested the behaviour of the "finish" command with a tail-recursive function in following code, with the following gdb commands: ------------------------------ static int f (int x); int main(void) { f(5); } static int f (int x) { if (x =3D=3D 0) { return 0; } else { return f(x - 1); } } ------------------------------ break f commands finish end ------------------------------ Given its documentation, I would have expected the "finish" command to print the returned value at each tail call. It turns out that it prints the returned value only for the f(0) call. I would similarly expect a "break on exit" command to break on the exit of the frame in which it is called even if a tail-recursion occurs. Is there a reason that it doesn't? My first thought would be tail-call optimisation, but in any case breaks on tail-calls of the function still work fine, and when I disassembled the function, I saw that no tail-call optimisation occurred in my case. On the actual implementation of this command: Is the implementation of such a feature feasible? If so, how much work would it take? I would certainly be interested in helping, although I don't yet have any experience with working on compilers/debuggers. On Sun, 17 Mar 2019 at 00:23, Simon Marchi wrote: > > On 2019-03-16 20:00, Andreas Schwab wrote: > > On M=C3=A4r 16 2019, Justin Paston-Cooper wro= te: > > > >> I can't imagine that I am the first person to suggest or request this. > >> Are > >> there any architectural or practical reasons as to why this is might > >> be > >> difficult? > > > > There may not even be a place where the frame is exited in the current > > function due to tail call. Also, inline literal pools or jump tables > > can result in false positives when searching for return insns. > > > > Andreas. > > I suppose that the list of all function exit points (regardless of > whether it is a jump or real return) is an information that the compiler > could theoretically produce and encode in the DWARF information? > > Simon