From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752397AbcAVIAE (ORCPT ); Fri, 22 Jan 2016 03:00:04 -0500 Received: from mail9.hitachi.co.jp ([133.145.228.44]:59918 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751416AbcAVH75 (ORCPT ); Fri, 22 Jan 2016 02:59:57 -0500 From: =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= To: "'Wangnan (F)'" , Arnaldo Carvalho de Melo , Ben Hutchings , He Kuang CC: Peter Zijlstra , Ingo Molnar , "linux-kernel@vger.kernel.org" , Jiri Olsa , Kaixu Xia , Zefan Li Subject: RE: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table Thread-Topic: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table Thread-Index: AQHRU4rY5coznL13SEKlLSIkpbzlJJ8EzngAgAI5w7D//3OGAIAAmc/w Date: Fri, 22 Jan 2016 07:59:53 +0000 Message-ID: <50399556C9727B4D88A595C8584AAB37B4DBA2B7@GSjpTKYDCembx31.service.hitachi.net> References: <20160119213213.GB2637@decadent.org.uk> <20160119213306.GE2637@decadent.org.uk> <20160120135924.GR27085@kernel.org> <56A061D8.80502@huawei.com> <50399556C9727B4D88A595C8584AAB37B4DBA0F8@GSjpTKYDCembx31.service.hitachi.net> <56A1C9F4.7070000@huawei.com> In-Reply-To: <56A1C9F4.7070000@huawei.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.219.44] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u0M808N1004642 >From: Wangnan (F) [mailto:wangnan0@huawei.com] >On 2016/1/22 13:56, 平松雅巳 / HIRAMATU，MASAMI wrote: >>> From: Wangnan (F) [mailto:wangnan0@huawei.com] >>> I think this problem is not introduced by my patch. In fact >>> there's a fundamental problem in get_arch_regstr() that it is >>> impossible to switch sub ISA. >> Right, but I guess this can fixed by switching %sp (for x86-64) >> and +0(%sp) (for x86-32) instead of $stack. >> > >It may not work. > >No matter how we change regoffset_table, when get_arch_regstr() >get a register number 4, how can it know whether we are looking >for x86_32 register and return $stack or return %si for x86_64? I think we can also use elf header to get the ISA of the target binary. >The fundamental problem is: we need a way to map dwarf's register >number to register names so uprobe know which register we are >looking for, but the API we designed for this can't distinguish >the sub ISAs dwarf are using. As I said, we can read the elf header and get the Class or Machine and switch the table according to it. Can't it? Thanks,