[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elisp native profiler

From: Tomohiro Matsuyama
Subject: Re: Elisp native profiler
Date: Fri, 28 Sep 2012 19:09:56 +0900

On Thu, 27 Sep 2012 07:55:55 +0200
Eli Zaretskii <address@hidden> wrote:

> > Date: Thu, 27 Sep 2012 07:46:55 +0900
> > From: Tomohiro Matsuyama <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden
> > 
> > > 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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]