From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 9CA06211B3 for ; Wed, 5 Dec 2018 07:05:24 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D73F81214A7; Wed, 5 Dec 2018 16:05:22 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2BFE9120D91 for ; Wed, 5 Dec 2018 16:05:21 +0900 (JST) Received: by filter0136p3las1.sendgrid.net with SMTP id filter0136p3las1-4685-5C0778AF-2A 2018-12-05 07:05:19.589480474 +0000 UTC m=+131932.106523178 Received: from herokuapp.com (ec2-54-227-61-106.compute-1.amazonaws.com [54.227.61.106]) by ismtpd0036p1iad1.sendgrid.net (SG) with ESMTP id Rv5J5BmtTTm-5lDhtAY9qA Wed, 05 Dec 2018 07:05:19.407 +0000 (UTC) Date: Wed, 05 Dec 2018 07:05:19 +0000 (UTC) From: ko1@atdot.net To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65694 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15313 X-Redmine-Issue-Author: alanwu X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: ko1 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS74OVUSInF8ls6+Xz9zGBNtS+s9bSWwm0aA82 TUSFLJXjemrDnA4hja6xCm2rZvPEdnbIvAy/PUthalnJrjwfQZ77VHkxussm9Ilaf5c8p2I30lTj6K Oat+0P6W/xPf+E+u71jGOoXkO0e1jy0vXokM X-ML-Name: ruby-core X-Mail-Count: 90301 Subject: [ruby-core:90301] [Ruby trunk Bug#15313] [PATCH] Let debuggers know when a tail call happens X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15313 has been updated by ko1 (Koichi Sasada). how about https://bugs.ruby-lang.org/issues/15303#note-2 ? ---------------------------------------- Bug #15313: [PATCH] Let debuggers know when a tail call happens https://bugs.ruby-lang.org/issues/15313#change-75408 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Target version: * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- ## Background The popular debugger "byebug" relies on tracepoint events to implement a few core functionality such as "next". The "next" command needs to pause execution when the VM reaches the next line on the same stack frame. As there is no direct way, using the public API, to tell the execution progress of a frame, Byebug keeps track of the currently executing frame by maintaining a counter using the "call" and "return" tracepoint event. https://github.com/deivid-rodriguez/byebug/blob/58ee5114aa856ec49483532a86fd159a877dd6ab/ext/byebug/byebug.c#L162-L170 Byebug's counter becomes incorrect when the interpreter performs a tail call, since after a tail call, the "return" event doesn't fire for the caller. #15303 This causes the "next" command to misbehave when stepping over code that performs tail call. https://github.com/deivid-rodriguez/byebug/issues/481 ## Proposed solution I implemented a new method in TracePoint that lets Byebug, or any other debugger to differentiate between a normal method call and a tail call. Using this API, Byebug can maintain the counter properly in the event of a tail call. Here are some other solutions - Some sort of public api that exposes execution progress of control frames. This might take a lot of effort. - Some sort of public api that give ids to stack frames. After a tail call, debuggers can use this to tell that a frame is different, even though it's on the same location on the stack. - Turning off tail call optimization in Forwardable. This side steps the problem but the core issue still remain. Third party libraries could still use tco and byebug wouldn't be able to work with them. Here are some downsides to my solution: - This is a pretty niche feature that only debuggers want - I'm adding a vm frame flag. While we have a few more bits to play with, it is a limited resource. ---Files-------------------------------- 0001-Add-a-tail-call-predicate-for-TracePoint.patch (18.1 KB) -- https://bugs.ruby-lang.org/