public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Prerna Saxena <prerna@linux.vnet.ibm.com>
Cc: Mark Wielaard <mjw@redhat.com>, systemtap@sourceware.org
Subject: Re: [Query] Re: dwarf unwinder (only works on i386/x86_64)
Date: Tue, 28 Apr 2009 18:19:00 -0000	[thread overview]
Message-ID: <20090428181720.4CBECFC3C6@magilla.sf.frob.com> (raw)
In-Reply-To: Prerna Saxena's message of  Tuesday, 28 April 2009 23:34:54 +0530 <49F74546.8040206@linux.vnet.ibm.com>

> I was trying to contrast the ".eh_frame" vs ".debug_frame" 
> specifications for keeping track of stack backtraces. Both appear rather 
> similar wrt information they maintain.

.debug_frame format is that specified in the formal DWARF standard.
.eh_frame format is a slight variant of that format, optimized for being
used by a process itself without address fixups.  (It is used by C++
exception handling, the backtrace() function, and so forth.)

> The Exception header ".eh_frame" section seems to be present in vmlinux 
> even when kernel is compiled without debuginfo.

This depends on lots of details of the kernel build that vary across
versions and machines.  In today's kernels, it is not usually there.

> i. what gcc flags cause this section to be compiled ?

-funwind-tables and similar options.

> ii. This section seemingly appears to be a better bet than DWARF to base 
> the unwinder on--- because a ".debug_frame" based unwinder might not be 
> useful in case of a kernel complied without debuginfo.

It is a somewhat hairy subject.  But in short, this is not so in current
kernels.  That is not entirely apropos, because it's only the situation for
the kernel, and there are also user binaries to consider.  There it is an
even more complex subject.  The overall answer is that the answer is complex,
but potentially both sections are involved.


Thanks,
Roland

  reply	other threads:[~2009-04-28 18:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 14:06 Mark Wielaard
2009-04-21 20:58 ` dwarf unwinder (only works on i386/x86_64) - now with user space unwinding Mark Wielaard
2009-05-21  8:03   ` dwarf unwinder (only works on i386/x86_64) - now with eh_frame and debug_frame fallback Mark Wielaard
2009-05-21 18:44     ` Roland McGrath
2009-05-21 22:57       ` Mark Wielaard
2009-05-22  1:19         ` Roland McGrath
2009-04-28 18:02 ` [Query] Re: dwarf unwinder (only works on i386/x86_64) Prerna Saxena
2009-04-28 18:19   ` Roland McGrath [this message]
2009-04-28 19:52     ` Mark Wielaard
2009-04-28 20:15       ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090428181720.4CBECFC3C6@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=mjw@redhat.com \
    --cc=prerna@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).