linux-kernel - Re: [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or 32-bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 May 2016 20:29:09 +0800
From:	Hekuang <hekuang@...wei.com>
To:	Adrian Hunter <adrian.hunter@...el.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



在 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.
>
>
>