From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751961AbcEJMaw (ORCPT ); Tue, 10 May 2016 08:30:52 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:32844 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751876AbcEJMav (ORCPT ); Tue, 10 May 2016 08:30:51 -0400 Subject: Re: [PATCH v2 5/9] perf tools: Add methods to test dso is 64-bit or 32-bit To: Adrian Hunter , , , , , , , , , , , , , , , , References: <1462866037-30382-1-git-send-email-hekuang@huawei.com> <1462866037-30382-6-git-send-email-hekuang@huawei.com> <573196E5.9080807@intel.com> <5731AEBB.8060200@huawei.com> <5731B94A.3070402@intel.com> <5731C844.9080406@huawei.com> <5731CD04.3000005@intel.com> CC: From: Hekuang Message-ID: <5731D415.8040808@huawei.com> Date: Tue, 10 May 2016 20:29:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5731CD04.3000005@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.110.55.166] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5731D425.0067,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 25fe009fb78b7579ab344c8ff7ca0ec5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 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. > > >