From: Mark Wielaard <mjw@redhat.com>
To: "平松雅巳 / HIRAMATU,MASAMI" <masami.hiramatsu.pt@hitachi.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"acme@kernel.org" <acme@kernel.org>,
"sukadev@linux.vnet.ibm.com" <sukadev@linux.vnet.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"srikar@linux.vnet.ibm.com" <srikar@linux.vnet.ibm.com>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: [PATCH] perf/probe: Search both .eh_frame and .debug_frame sections for probe location
Date: Thu, 24 Sep 2015 13:23:12 +0200 [thread overview]
Message-ID: <1443093792.3102.42.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: <50399556C9727B4D88A595C8584AAB37525585E9@GSjpTKYDCembx32.service.hitachi.net>
On Thu, 2015-09-24 at 10:56 +0000, 平松雅巳 / HIRAMATU,MASAMI wrote:
> >I am not too familiar with the code so there might be a reason for
> >setting and reusing the pf->cfi to do the search twice. But might it not
> >be more clear to just store both pf->cfi_eh and pf->cfi_debug and then
> >check both in call_probe_finder () with the dwarf_cfi_addrframe () call?
> >Which is the only place I see actually using the cfi.
>
> Right, but since call_probe_finder can be called repeatedly on same binary,
> we should keep pf->cfi for caching CFI too.
Yes. I was suggesting to rename pf->cfi to pf->cfi_eh and add
pf->cfi_debug, to make clear why there are two.
> >BTW. Not really related to this patch since the following was already in
> >the code, and is most likely always correct anyway:
> >
> >> + if (elf_section_by_name(elf, &ehdr, &shdr, ".eh_frame", NULL) &&
> >> + shdr.sh_type == SHT_PROGBITS) {
> >> + pf->cfi = dwarf_getcfi_elf(elf);
> >
> >But that SHT_PROGBITS check is only necessary because of a bug in
> >elfutils < 0.156. For 0.156+ dwarf_getcfi_elf () will properly return
> >NULL in case you happen to be looking at a separate debug file that
> >has .eh_frame as NOBITS. In theory this prevents getting the CFI if the
> >file has stripped away the shdrs. Which is reasonable, there are
> >probably also other things that rely on the shdrs.
>
> Ah, I had just wanted to avoid introducing new ifdefs.
Yes, understandable. It is a weird corner case anyway.
> > But dwarf_getcfi_elf
> >is able to also get you the CFI with just the phdrs.
>
> Hmm, how can I make such binary? I can fix it, but we need a
> testcase for that.
eu-strip --strip-sections can create such binaries. But honestly I
wouldn't bother. They are basically useless and nobody (should) do that.
The only reason you might want to support them is for getting a
backtrace anyway through the CFI. But you won't be able to get any other
symbol or debug information from them.
I only really mentioned it because I am embarrassed about the bug in
elfutils. Just glad that it got fixed and the workaround isn't necessary
anymore. But it probably is not worth it now to try to remove the
workaround. There is no real benefit in this case.
Cheers,
Mark
prev parent reply other threads:[~2015-09-24 11:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 2:16 Hemant Kumar
2015-09-24 9:59 ` Mark Wielaard
2015-09-24 10:56 ` 平松雅巳 / HIRAMATU,MASAMI
2015-09-24 11:23 ` Mark Wielaard [this message]
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=1443093792.3102.42.camel@bordewijk.wildebeest.org \
--to=mjw@redhat.com \
--cc=acme@kernel.org \
--cc=hemant@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=sukadev@linux.vnet.ibm.com \
/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
all inboxes | Powered by JetHome®