From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tomohiro Matsuyama Newsgroups: gmane.emacs.devel Subject: Re: Elisp native profiler Date: Fri, 28 Sep 2012 19:09:56 +0900 Message-ID: <20120928190956.3ec9efaa97178d2e16ad6179@cx4a.org> References: <83zk4egs0w.fsf@gnu.org> <83y5jygrni.fsf@gnu.org> <50620443.8050301@cs.ucla.edu> <20120926151625.229ef3cc9caf90e5098b18ef@cx4a.org> <83ipb1grs9.fsf@gnu.org> <20120926165946.87a9f8c58aad890dafb50494@cx4a.org> <83d319gmd6.fsf@gnu.org> <20120927074655.a943e298fc9319a438825f47@cx4a.org> <83wqzgf1qs.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348827020 9216 80.91.229.3 (28 Sep 2012 10:10:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 10:10:20 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 28 12:10:24 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1THXWa-0005cO-0z for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 12:10:24 +0200 Original-Received: from localhost ([::1]:45375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THXWU-00030x-MG for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 06:10:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THXWN-00030p-IP for emacs-devel@gnu.org; Fri, 28 Sep 2012 06:10:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THXWH-0004lS-Do for emacs-devel@gnu.org; Fri, 28 Sep 2012 06:10:11 -0400 Original-Received: from www6399u.sakura.ne.jp ([59.106.183.193]:54226 helo=cx4a.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THXWA-0004Yj-9z; Fri, 28 Sep 2012 06:09:58 -0400 Original-Received: from thinkpad (p16049-ipngn1901hodogaya.kanagawa.ocn.ne.jp [180.11.9.49]) by cx4a.org (Postfix) with ESMTPSA id A06A586C91; Fri, 28 Sep 2012 19:09:55 +0900 (JST) In-Reply-To: <83wqzgf1qs.fsf@gnu.org> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 59.106.183.193 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153669 Archived-At: On Thu, 27 Sep 2012 07:55:55 +0200 Eli Zaretskii wrote: > > Date: Thu, 27 Sep 2012 07:46:55 +0900 > > From: Tomohiro Matsuyama > > Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > > > So what do you need, in addition to the name of the primitive, that is in > > > siginfo_t and ucontext_t? > > What I wanted to say here is that we need to get a stack pointer of the > > running main thread to obtain C-level backtrace. > > Sorry, I don't understand: if all you need is to profile primitives, > why do you need a full C-level backtrace? The primitives called are > already available in the backtrace_list structure, aren't they? No, because C-level function calls like Fvertical_motion could never been listed in backtrace_list. That's why byte-code often appears at top in a profiling result. > > In my understand, the > > stack pointer is not available to other threads without firing signals. > > It's possible on Windows. If it isn't possible with pthreads, that's > just too bad. Anyway, getting at the stack pointer does not yet give > you the backtrace. I explored pthread manual, but I didn't finally find anything like that. > > By the way, is it easy to obtain C-level backtrace? gdb and addr2line might > > help me, but I want a small and portable library for that. > > See emacs_backtrace on sysdep.c. Not sure about the portability of > the underlying APIs. Great! > AFAIK, any backtrace facility is specific to the object file format > and the debug info used by the platform. Compiler optimizations and > various non-local jumps complicate things a lot. My suggestion would > be not to go there, unless absolutely needed and desirable, because it > most probably be in a constant need of maintenance to keep up with > development of the underlying platform, compilers, etc. How do you think about inserting a backtrace building code (like Ffuncall does) into DEFUN macro expansion if specified so in configure script, for example? This could be fully portable, but involves some overhead. Tomohiro