From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 05:37:45 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75CAE106566C for ; Tue, 12 Jun 2012 05:37:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BAE9F8FC0C for ; Tue, 12 Jun 2012 05:37:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA05390; Tue, 12 Jun 2012 08:37:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SeJnK-0006vZ-P4; Tue, 12 Jun 2012 08:37:34 +0300 Message-ID: <4FD6D59E.5040809@FreeBSD.org> Date: Tue, 12 Jun 2012 08:37:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4FD490D5.1070207@FreeBSD.org> <20120610152721.3b627896@fabiankeil.de> <4FD4CD8B.1080803@FreeBSD.org> <4FD5109D.5090107@FreeBSD.org> <4fd5cd2b.SwlSDIgKvkib2N6C%perryh@pluto.rain.com> In-Reply-To: <4fd5cd2b.SwlSDIgKvkib2N6C%perryh@pluto.rain.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, rysto32@gmail.com, freebsd-listen@fabiankeil.de Subject: Re: decoding of multi-byte nops in dtrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 05:37:45 -0000 on 11/06/2012 06:49 perryh@pluto.rain.com said the following: > Sounds as if DTrace could use an improvement to recognize and handle > the tail call optimization, maybe something along the lines of: > > If a function has no otherwise-determined return probe > and it contains a jump to the entry point of another function > then it inherits that other function's return probe. > > I'd expect that to handle cases like > > int bar(...) > { > ... > return baz; > } > > int foo(...) > { > ... > return bar(...); > } > > (although probably not cases where the return in foo calls a > function pointer). And no, I am not volunteering to add it -- > ENOTIME :( (Open)Solaris fdt code for sparc already handles this case (last instruction in a function being a call), but not any other implementation. Not sure if that is for technical reasons or if nobody just bothered. -- Andriy Gapon