[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5731CD04.3000005@intel.com>
Date: Tue, 10 May 2016 14:59:00 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Hekuang <hekuang@...wei.com>, peterz@...radead.org,
mingo@...hat.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
wangnan0@...wei.com, jpoimboe@...hat.com, ak@...ux.intel.com,
eranian@...gle.com, namhyung@...nel.org,
sukadev@...ux.vnet.ibm.com, masami.hiramatsu.pt@...achi.com,
tumanova@...ux.vnet.ibm.com, kan.liang@...el.com,
penberg@...nel.org, dsahern@...il.com
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or
32-bit
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()
Powered by blists - more mailing lists