From: Omar Sandoval <osandov@osandov.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame
Date: Wed, 30 Oct 2019 23:55:00 -0000 [thread overview]
Message-ID: <20191030235551.GJ326591@vader> (raw)
In-Reply-To: <7be679675894550820b63e7c08a5495d06ac49a8.camel@klomp.org>
On Wed, Oct 30, 2019 at 02:04:42PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > The next change will need to have the Dwarf_Frame readily available, so
> > rather than finding it again every time, let's cache it for reuse. The
> > CFI frame can also be useful to clients of libdwfl, so add
> > dwfl_frame_dwarf_frame to get it. Similarly, the Dwfl_Module is also
> > frequently needed in conjunction with the frame, so cache it and add
> > dwfl_frame_module.
>
> I can see how this is useful. But it seems the Dwarf_Frame is only
> cached when __libdwfl_frame_unwind is called. Which I believe isn't
> done for the initial frame. Also it isn't clear how to propagate any
> errors when NULL is returned. Maybe dwfl_frame_dwarf_frame () should
> check first to see if frame is NULL and then call lookup the CFI and
> call dwarf_cfi_addrframe if not?
Yes, that makes sense. Rather than doing the lookups in
__libdwfl_frame_unwind and handle_cfi, I can move the lookups to
dwfl_frame_module and dwfl_frame_dwarf_frame, have those functions cache
it internally, and make __libdwfl_frame_unwind and handle_cfi call those
functions.
Thanks,
Omar
next prev parent reply other threads:[~2019-10-30 23:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 9:05 [PATCH 0/5] libdwfl: expand stack frame interface Omar Sandoval
2019-10-07 9:05 ` [PATCH 2/5] libdwfl: only use thread->unwound for initial frame Omar Sandoval
2019-10-29 22:20 ` Mark Wielaard
2019-10-07 9:05 ` [PATCH 5/5] libdwfl: add interface for evaluating DWARF expressions in a frame Omar Sandoval
2019-10-30 13:23 ` Mark Wielaard
2019-10-30 23:59 ` Omar Sandoval
2019-10-31 16:40 ` Mark Wielaard
2019-10-07 9:05 ` [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame Omar Sandoval
2019-10-30 13:04 ` Mark Wielaard
2019-10-30 23:55 ` Omar Sandoval [this message]
2019-10-31 16:29 ` Mark Wielaard
2019-10-07 9:05 ` [PATCH 1/5] libdwfl: don't bother freeing frames outside of dwfl_thread_getframes Omar Sandoval
2019-10-29 15:55 ` Mark Wielaard
2019-10-29 16:17 ` Omar Sandoval
2019-10-29 16:52 ` Mark Wielaard
2019-10-07 9:05 ` [PATCH 3/5] libdwfl: add interface for attaching to/detaching from threads Omar Sandoval
2019-10-30 12:47 ` Mark Wielaard
2019-10-30 23:49 ` Omar Sandoval
2019-10-31 16:21 ` Mark Wielaard
2019-10-31 17:13 ` Omar Sandoval
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=20191030235551.GJ326591@vader \
--to=osandov@osandov.com \
--cc=elfutils-devel@sourceware.org \
--cc=mark@klomp.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).