From owner-freebsd-hackers@freebsd.org Wed Oct 24 17:23:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBA11FFDE46 for ; Wed, 24 Oct 2018 17:23:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66FFC6FB3E; Wed, 24 Oct 2018 17:23:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it1-x144.google.com with SMTP id m15so7596804itl.4; Wed, 24 Oct 2018 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3Ox9HWNiZkEaQYY9+ILgJUrPajvUOAJCp15D0R7DRvo=; b=bQZmDL3PV+9W8x+wQpas6IqzJRiIszr+pEW5JJ2Ob2BfdL2mTsT0uYxNqr//CMQVYN nrChQzu30xpwya3vdd6HLWxCHnwF6sktBmj7thXF3UkfGkOn3xkOhkgef1/LX3PyOKb3 rcHfumo8nXQh4BsWYcdEJU7S5HSOnXitJpC7cXo9yYHqDQFngsCtoMclBe2jg37DPYdG etPzFGlpo2UjP2SgOlSVb98wdK++0cmSZPo/Redg7C5jydu5KqImler12T2eYezNSojq gkP3wPIWBTXFpugy9z7yZLO2NB+l6riQQ5MbUxQFHnEvCDV07mpIOje3Sm8vBy5GclIz tgEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=3Ox9HWNiZkEaQYY9+ILgJUrPajvUOAJCp15D0R7DRvo=; b=TlCXh3907OQ46NwbOxXloenLl/g8X+//ap5faVPonsAzODtk7fz+xz18S7e60oTwfQ LwF0irNjVB133gov0FaPDss8TeE7JHdewxtFCjxuTA4xn3PMaD5Cmhy1tr4gEcOB2nmz moCvGZVKlAaeW3oLI5LXmPjCnO58JSWCj0GczRMvaDHWnuI+7Vb/QR3IKiz+ilnk0jDm BGvUDuhUBWk5nEQu0SPGgsOepfDTNZQts3Lwp40d6GGI+v0SVHdd9et/Mb486OSe+7J1 xTzk+TfSnjquDjwQlOGops2CxM4ck2vJM/rQEWfFwDrw1N536wPrHoUZVFBy0XP1ALPc DDhQ== X-Gm-Message-State: AGRZ1gKBI036+55Rd4b7eAtgtzvcTXAJ0PunLGITtVddk8AIvW1XM5+y u6s+ZFqf/PQPMmA16gXlbYs= X-Google-Smtp-Source: AJdET5cXJIMu48EikNYUflQuxoNkWq6xp15gvUEWEr+9SnljBe9bKil3U7sOxHSG0Yk0mdV9UKfH8A== X-Received: by 2002:a02:b5c1:: with SMTP id y1-v6mr2496296jaj.143.1540401785517; Wed, 24 Oct 2018 10:23:05 -0700 (PDT) Received: from raichu (toroon0560w-lp130-08-67-71-176-199.dsl.bell.ca. [67.71.176.199]) by smtp.gmail.com with ESMTPSA id t25-v6sm2696093iob.73.2018.10.24.10.23.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 10:23:04 -0700 (PDT) Sender: Mark Johnston Date: Wed, 24 Oct 2018 13:23:02 -0400 From: Mark Johnston To: Ryan Stone Cc: lev@freebsd.org, freebsd-hackers@freebsd.org, Conrad Meyer , Alan Somers Subject: Re: What is wrong with dtrace's stack()? Message-ID: <20181024172302.GF45118@raichu> References: <475670271.20181022003734@serebryakov.spb.ru> <234d745d-37a9-9610-15b9-0f5cd5af21bf@FreeBSD.org> <168122586.20181024003412@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 17:23:07 -0000 On Wed, Oct 24, 2018 at 01:14:10PM -0400, Ryan Stone wrote: > ia32_pause() is an inline function. How does dtrace map instruction > pointers to symbol names? It uses a kernel linker API whose implementation searches the symbol tables of the kernel and loaded KLDs. > Is it getting that mapping from some CTF > data, and is that CTF data aware of inline functions? No, and no. CTF does include a function table, but that's just for encoding function parameter and return types. Functions that get inlined into every caller (as I'd expect with ia32_pause()) shouldn't be showing up in stack traces. There is no ia32_pause() symbol in my kernel; presumably the observed behaviour is related to some non-default compiler flags being used, but I haven't carefully read through the whole thread to see. > If so, I'd argue that behaviour is counter-intuitive and unhelpful, as > this example here shows.