public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Mark Wielaard <mjw@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: dwarf unwinder (only works on i386/x86_64) - now with eh_frame  and debug_frame fallback
Date: Thu, 21 May 2009 18:44:00 -0000	[thread overview]
Message-ID: <20090521184400.1A58EFC38D@magilla.sf.frob.com> (raw)
In-Reply-To: Mark Wielaard's message of  Thursday, 21 May 2009 10:03:31 +0200 <1242893011.3655.47.camel@hermans.wildebeest.org>

> The "ugly" code in these patches is in adjustStartAddress() in
> runtime/unwind.c. This really should go into _stp_module_relocate or
> read_pointer. One tricky issue here is that we read the eh_frame section
> during translation time and then load it in kernel space at module init
> time. eh_frame tables can use pointer encodings that are absolute or
> pc_relative (actually data relative), so we need to readjust for the new
> load location of the eh_frame.

In the long run I think the right thing here will be to convert the data at
translation time.  That is, make all addresses use a simple "absolute" form
(as is usual in .debug_frame), which really means "loadbase-relative" for
DSOs--i.e., the same as addresses in the symbol table, etc.  Then at run
time you just have one uniform way to treat addresses in each module.
That keeps things as simple as possible at runtime.

> Some optimizations that could be done:
> - Use the eh_frame_hdr binary search table
>   (needs careful auditing of adjustStartAddress -> read_pointer).
[...]
> - Merge debug_frame and eh_frame at runtime and build our own
>   binary search hdr.

By "runtime" here, you mean "translation time", right?  In the unspecified
future, elfutils libs will provide easy-to-use code for merging tables,
emitting them in whichever format, and generating binary search tables.
Probably any such optimization concerns can wait for that.


Thanks,
Roland

  reply	other threads:[~2009-05-21 18:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 14:06 dwarf unwinder (only works on i386/x86_64) 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 [this message]
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
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=20090521184400.1A58EFC38D@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=mjw@redhat.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).