Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5415769rwb; Mon, 8 Aug 2022 19:17:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR4gDyvtQ5XH1wyGmTEGdOu0t+4HWMT04TDOp0nuE8iXzKkm1q0QqBN8acunOaCgZInA4VH6 X-Received: by 2002:a17:902:7442:b0:16d:b480:31eb with SMTP id e2-20020a170902744200b0016db48031ebmr21231090plt.157.1660011475851; Mon, 08 Aug 2022 19:17:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660011475; cv=none; d=google.com; s=arc-20160816; b=wJZnt+0MAl6YPiKy3MLIH/ahKDgsFNOWZ5jjG6gdpJTOUmw524ImY+L6BuEfr5BK7N uGibjcjiEw+WsRoK3Sjm0YrxNLKXui61Bu1JPcVfezlPfFs+ALUGn7FIdeUDGXk66JMF 7svLiZ+FL3OB+A54vQpS3wZ7fnbB4UR5ekWOilAkAgpk6Bce0VdE9bKhm7HHdB9kDWCm eVNWlL5wIbaNRXlwJmqp38tFO2+vkJodneBpd73cVRBtNwBk3ylyJkQ13xi9jLV905bG FDLGVoqB9lRiJPdU0gGMIf7sWOW8RdQP+VJDMaMAySmxKgP27T4pQ/YfGjG7c17iN9d+ qeqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=WxuaUwV4hVlwuwXWqcbqza+VxL9pLR+vXVErtMNVLDE=; b=m/LQw/VgE8/RX2WcZZnH7mFfCGh93ssJpenvV9bmS72tnk+8PlCNzovcPpDNhGvwWI WxV4ODViWennxl+DQ3KDsHhvTf/nTo2aFXCLq/XiUzVxtqUmNS1oxfgqjZhNw5CdAdhR /NTYFzo8OCFD7LPSWP9L3q/Okh+tyy+PlgmUK5Dqd8tUk96+k08Zgt6La1IvlgqPKpig 9jkHMTPSTJBe6LmXc8Umxeh4kmQvaWcecXTGgOLJz+K3AoUxs0gkmq0sNghTMkaSxFdS cL1c8iap18m/Vj4RWJf8oIWey6AKPBci7zy19W0DvPf5xgklb4XBeAl9ukjhluoowJaA gKZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g7-20020a63be47000000b00412a9c29e5bsi5880807pgo.702.2022.08.08.19.17.41; Mon, 08 Aug 2022 19:17:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229593AbiHICKv (ORCPT + 99 others); Mon, 8 Aug 2022 22:10:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242451AbiHICJZ (ORCPT ); Mon, 8 Aug 2022 22:09:25 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C67811A393 for ; Mon, 8 Aug 2022 19:09:21 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4M1xKJ4SlrzmVZL; Tue, 9 Aug 2022 10:07:16 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 9 Aug 2022 10:09:18 +0800 Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 9 Aug 2022 10:09:18 +0800 Subject: Re: [PATCH] ARM: Remove the special printing format of pc and lr in __show_regs() To: "Russell King (Oracle)" CC: , , References: <20220801032016.1524-1-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <9f630d80-68c7-8816-f2f6-7e39c890c4d1@huawei.com> Date: Tue, 9 Aug 2022 10:09:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/8/8 17:41, Russell King (Oracle) wrote: > On Mon, Aug 01, 2022 at 11:20:16AM +0800, Zhen Lei wrote: >> Currently, instruction pointers are printed in [<%08lx>] format to make >> them more visible. However, it is not necessary in __show_regs() because >> they have the prefix 'pc :' or 'lr :', and it is also inconsistent with >> that of other registers, which causes misalignment. > > The formatting is not "to make them more visible" - it was to mark the > addresses that we wanted the ksymoops utility to translate to kernel > symbols before we had kallsyms in the kernel. If one disables kallsyms, > then we still need a way to translate kernel addresses to symbols. I searched the git log and found that the ksymoops utility is discarded. See: 073a9ecb3a73401662430bb955aedeac1de643d1 However, a commit in the pre-git era [1] had added the statement, "ksymoops is useless on 2.6. Please use the Oops in its original format". That statement existed until commit 4eb9241127a0 ("Documentation: admin-guide: update bug-hunting.rst") finally removed the stale ksymoops information. 4eb9241127a0b5ac3aaaf1b246728009527ebc86 - delete all references to ksymoops since it is no longer applicable; > > I notice there is a script which helps with this that is part of the > kernel source - scripts/decode_stacktrace.sh. I haven't tried this on > arm32 since I always use kallsyms - and I suspect that is rather > universally true as it avoids needing System.map files etc to decode > the oops. That said, if you're building a kernel for small systems, > you probably don't want the overhead of kallsyms. Yes, I read scripts/decode_stacktrace.sh, it requires the format "[<...>]". But if that's the only concern, maybe we can do the conversion from "pc: addr" and "lr: addr" to "[]" first in scripts/decode_stacktrace.sh I'm usually "objdump -d vmlinux > asm_file", then search "addr:" in asm_file. Honestly, I think format "[<...>]" is dump_backtrace()'s requirement, not __show_regs()'s. > > So, there's an argument for keeping it - it's an API in that it > provides hints to scripting to identify which values need to be > converted to symbols. There's also the argument for getting rid of it, > which is that hardly anyone does that anymore. > > The question is, which is the more important argument, and I don't > think there's a definite answer. So I'm inclined to leave this > as-is. OK > -- Regards, Zhen Lei