lkml.org 
[lkml]   [2016]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or 32-bit
From
Date


在 2016/5/10 19:59, Adrian Hunter 写道:
> 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()

IMO, map__load() is heavy than dso_is_64_bit() test, because the
dso tested by unwind_get_arch(thread, map) may or may not be
referenced in the unwind process. For example, a thread can
have a large map but that map never appeared in the callcains
in perf.data.

Or in other words, should we load all symbols for that elf flag or
add a new method targeted for that purpose only.

Thanks.
>
>
>


\
 
 \ /
  Last update: 2016-05-10 14:41    [W:0.059 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site