From: Adrian Hunter <adrian.hunter@intel.com>
To: Hekuang <hekuang@huawei.com>,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
wangnan0@huawei.com, jpoimboe@redhat.com, ak@linux.intel.com,
eranian@google.com, namhyung@kernel.org,
sukadev@linux.vnet.ibm.com, masami.hiramatsu.pt@hitachi.com,
tumanova@linux.vnet.ibm.com, kan.liang@intel.com,
penberg@kernel.org, dsahern@gmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or 32-bit
Date: Tue, 10 May 2016 14:59:00 +0300 [thread overview]
Message-ID: <5731CD04.3000005@intel.com> (raw)
In-Reply-To: <5731C844.9080406@huawei.com>
On 10/05/16 14:38, Hekuang wrote:
>
>
> 在 2016/5/10 18:34, Adrian Hunter 写道:
>> On 10/05/16 12:49, Hekuang wrote:
>>> hi
>>>
>>> 在 2016/5/10 16:08, Adrian Hunter 写道:
>>>> On 10/05/16 10:40, He Kuang wrote:
>>>>> 32-bit programs can be run on 64-bit machines, so we should choose
>>>>> unwind methods according to 'thread->map' instead of the host
>>>>> architecture.
>>>>>
>>>>> This patch adds methods to test whether a dso is 64-bit or 32-bit by
>>>>> the class info in elf.
>>>> What about using dso->is_64_bit set by dso__load_sym() ?
>>> I've noticed this variable, but it's value is not as its name said:
>>>
>>> util/dso.c: 1067 dso->is_64_bit = (sizeof(void *) == 8);
>> That is just initialization i.e. before we know what it is we assume it is
>> the same as the host.
>>
>>> This is only related to the host architecture.
>>>
>>> A closer one is 'is_64_bit' in 'struct symsrc', but the value is assigned
>>> after dso
>>> loaded. So I think we should provide individual methods to get that value.
>> Are you saying you don't load dsos? Or that is_64_bit is set incorrectly?
>>
>
> Yes, I know it's the inital value, but the correct value is
> assigned in function dso__load_sym(), and have a look at the call
> stack(gdb):
>
> #0 dso__load_sym
> #1 in dso__load
> #2 in map__load
> #3 in map__find_symbol
> #4 in thread__find_addr_location
> #5 in entry
> #6 in get_entries
> #7 in _Ux86__unwind__get_entries
> #8 in thread__resolve_callchain
>
> I think we should choose the right unwind method before
> dso__load_sym(). i.e. line#7, which is called before dso__load_sym().
>
> I'm not very familiar with this, what's your opinion?
Have you considered calling map__load() instead of dso_is_64_bit()
next prev parent reply other threads:[~2016-05-10 12:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 7:40 [PATCH v2 0/9] Add support for remote unwind He Kuang
2016-05-10 7:40 ` [PATCH v2 1/9] perf tools: Omit DWARF judgement when recording dwarf callchain He Kuang
2016-05-10 13:45 ` Arnaldo Carvalho de Melo
2016-05-10 7:40 ` [PATCH v2 2/9] perf script: Add options for custom vdso path He Kuang
2016-05-10 13:44 ` Arnaldo Carvalho de Melo
2016-05-11 1:33 ` Hekuang
2016-05-10 7:40 ` [PATCH v2 3/9] perf build: Add build-test for libunwind cross-platforms support He Kuang
2016-05-11 11:52 ` Jiri Olsa
2016-05-11 13:24 ` Arnaldo Carvalho de Melo
2016-05-12 10:23 ` [tip:perf/core] " tip-bot for He Kuang
2016-05-10 7:40 ` [PATCH v2 4/9] perf build: Add build-test for debug-frame on arm/arm64 He Kuang
2016-05-11 11:58 ` Jiri Olsa
2016-05-11 13:24 ` Arnaldo Carvalho de Melo
2016-05-12 10:24 ` [tip:perf/core] " tip-bot for He Kuang
2016-05-10 7:40 ` [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or 32-bit He Kuang
2016-05-10 8:08 ` Adrian Hunter
2016-05-10 9:49 ` Hekuang
2016-05-10 10:34 ` Adrian Hunter
2016-05-10 11:38 ` Hekuang
2016-05-10 11:59 ` Adrian Hunter [this message]
2016-05-10 12:29 ` Hekuang
2016-05-10 7:40 ` [PATCH v2 6/9] perf tools: Promote proper messages for cross-platform unwind He Kuang
2016-05-10 7:40 ` [PATCH v2 7/9] perf callchain: Add support " He Kuang
2016-05-10 7:40 ` [PATCH v2 8/9] perf callchain: Support x86 target platform He Kuang
2016-05-10 7:40 ` [PATCH v2 9/9] perf callchain: Support aarch64 cross-platform He Kuang
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=5731CD04.3000005@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=hekuang@huawei.com \
--cc=jolsa@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=sukadev@linux.vnet.ibm.com \
--cc=tumanova@linux.vnet.ibm.com \
--cc=wangnan0@huawei.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.