From: Adrian Hunter <adrian.hunter@intel.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "acme@redhat.com" <acme@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kristina Martsenko <Kristina.Martsenko@arm.com>,
Vladimir Nikulichev <nvs@tbricks.com>,
Namhyung Kim <namhyung@kernel.org>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH v2] perf tools: don't adjust symbols in vDSO
Date: Tue, 30 Jun 2015 12:57:04 +0300 [thread overview]
Message-ID: <559267F0.6@intel.com> (raw)
In-Reply-To: <20150629135238.GC17474@arm.com>
On 29/06/15 16:52, Will Deacon wrote:
> On Mon, Jun 29, 2015 at 02:23:51PM +0100, Adrian Hunter wrote:
>> On 29/06/15 15:30, Adrian Hunter wrote:
>>> On 29/06/15 12:02, Adrian Hunter wrote:
>>>> On 27/06/15 12:10, Will Deacon wrote:
>>>>> @@ -824,6 +823,14 @@ int dso__load_sym(struct dso *dso, struct map *map,
>>>>> sec = syms_ss->symtab;
>>>>> shdr = syms_ss->symshdr;
>>>>>
>>>>> + /*
>>>>> + * Older x86 kernels prelink the vDSO at a high address, so
>>>>> + * we need to reflect that in map->pgoff in order to talk to
>>>>> + * objdump.
>>>>> + */
>>>>> + if (dso__is_vdso(dso))
>>>>> + map->pgoff = shdr.sh_addr - shdr.sh_offset;
>>>>
>>>> In the case of perf tools, maps map memory addresses to file offsets.
>>>> That is used to read from the object file, so you can't change the map.
>>>
>>> So what about just this instead:
>>>
>>> if (dso__is_vdso(dso))
>>> map->reloc = shdr.sh_addr - shdr.sh_offset;
>>>
>>
>> No that's no good either :-(
>
> Yeah... we're fighting against symbol lookup wanting ->map_ip to give the
> address of the ELF symbol but unwinding wanting ->map_ip to give a relative
> offset for file reads.
>
> Also, the reloc is a bit weird and I think needs to be the other way around
> (i.e. we convert from a map-relative address to an objdump address by
> *subtracting* the reloc). Even with that change, I run into problems with
> annotate comparing ELF symbol addresses with map addresses. Urgh.
Adding or subtracting shouldn't matter.
This seems to work (without any other changes):
if (dso__is_vdso(dso))
map->reloc = map->start - shdr.sh_addr + shdr.sh_offset;
Haven't tested 32-bit yet though.
next prev parent reply other threads:[~2015-06-30 9:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-27 9:10 [PATCH v2] perf tools: don't adjust symbols in vDSO Will Deacon
2015-06-29 9:02 ` Adrian Hunter
2015-06-29 12:30 ` Adrian Hunter
2015-06-29 13:23 ` Adrian Hunter
2015-06-29 13:52 ` Will Deacon
2015-06-29 14:55 ` acme
2015-06-30 9:57 ` Adrian Hunter [this message]
2015-06-30 10:47 ` Will Deacon
2015-07-09 10:12 ` Will Deacon
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=559267F0.6@intel.com \
--to=adrian.hunter@intel.com \
--cc=Kristina.Martsenko@arm.com \
--cc=acme@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=namhyung@kernel.org \
--cc=nvs@tbricks.com \
--cc=will.deacon@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.