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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ