From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 607B2C433E0 for ; Tue, 2 Feb 2021 03:38:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1609264ECE for ; Tue, 2 Feb 2021 03:38:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1609264ECE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/BYUw/B/zeFOlr2W+9EoW6T1Bt0Eqmc4SatSFMFQGgQ=; b=3Dr+ADJPh+ZMTCYUwDEV1vsTJ 0ZpJCJQO7KE0SXtAwNLC4/sNXBPbXTsKz67wWS0woGsaPFSgwy5KZEd5pM+fjKc06/uTfsyUee109 YDV8g0prpnhm0r4NqAMra0EAobCMiL4eYkfFIHlhr3sHr2jA6xJ71yyKeL0VJDSuQh69yDRHEJk3v 0tclJ9ak9TSeznQBz0f8/HTcFAhpMyTipMtkC2yxC9Vi+8466pYHQ3ht2hFt9Y2JGGC9bxvD96IbE TPIgluDx0oyHECf0v9kUnc2yDxQWE7jxlREGDCegFwXCz0kFtpM8PbBUYEIqJF0u8QJcEl84elK8g I37lTIgmA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6mUk-0000UN-9w; Tue, 02 Feb 2021 03:36:50 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6mUh-0000U4-05 for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 03:36:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612237005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i7Ls+NbzUVxA+n8Sxw/7Mw6ZKR3HkdopfEISeCzUaYg=; b=dhYyQT6vOrz4v7wSM//7rY7Mt3HSnVeAkQnsYa9eClZDsXeAeIB3wF93m6Ta6uPVL7flgw gVUZeYFw0EUcEji0GgV2Sm7KYjo3Y6joIJqefE8XrAnGKNEtgummWuZxeCvyGi+meZ7esR v6hjLpYU2WrfGS5aOVIW5DxpmIbZeQQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-KlXsWcscPvKh_28QNm_qNQ-1; Mon, 01 Feb 2021 22:36:44 -0500 X-MC-Unique: KlXsWcscPvKh_28QNm_qNQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5FED3107ACE3; Tue, 2 Feb 2021 03:36:42 +0000 (UTC) Received: from treble (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C7F05D9D5; Tue, 2 Feb 2021 03:36:41 +0000 (UTC) Date: Mon, 1 Feb 2021 21:36:39 -0600 From: Josh Poimboeuf To: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210202033639.mjusaoqrbshzgjjl@treble> References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> <20210128142250.GC4537@sirena.org.uk> <20210128152649.6zin3hzim3etbv2p@treble> <20210201160225.GD66060@C02TD0UTHF1T.local> <20210201230032.syuv2nrbbureszbu@treble> <44a32a13-f744-b591-a68d-19cf665e5495@linux.microsoft.com> MIME-Version: 1.0 In-Reply-To: <44a32a13-f744-b591-a68d-19cf665e5495@linux.microsoft.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jpoimboe@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210201_223647_084983_1523F38E X-CRM114-Status: GOOD ( 17.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Julien Thierry , Catalin Marinas , Mark Brown , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 01, 2021 at 08:29:52PM -0600, Madhavan T. Venkataraman wrote: > The no-ops were just a wild idea of mine. I knew I would rue it as soon as I hit > the send button :-) That's ok, I like wild ideas :-) > > The original version of objtool was an awk script which basically just > > crudely looked for the prologue/epilogue instructions. It mostly > > worked. > > > > But it wasn't 100%, and these days the prologue isn't always at the > > beginning, and the epilogue is usually buried in the middle. And > > sometimes there are more stack pushes/pops hidden outside of the formal > > prologue/epilogue. Not to mention asm code which does all kinds of > > crazy things. And other edge cases, like leaf functions which don't > > require frame pointers, and alternatives patching/paravirt/etc which can > > muck with the stack layout at runtime. Eventually we realized a "full > > coverage" objtool is the wisest approach. > > > > Yes. I studied the objtool code. It does a fantastic job for X86. I suspect > it took a lot of time and a lot of work to get it right. It is > just that adding complete static analysis for an arch is daunting and > time consuming. How would we ever prove to the community that we are > truly done? Objtool makes sure to visit all instructions in the file. Otherwise it prints an "unreachable instruction" warning. That's how we make sure to get full coverage. And most compiled code is pretty straightforward, so the static analysis is mostly "just" a matter of monitoring stack operations and following the branches. Of course, the devil's in the details. It gets battle-tested pretty well with randconfigs across a lot of different compiler versions. When it encounters some situation it doesn't understand, it complains, and we hear about it. Julien and Raphael already laid a lot of the groundwork for porting it to new arches, so as you can see with Julien's latest series there's not much to do beyond adding the instruction decoder, and then looking at all the warnings. Sometimes warnings are legit, and other times they mean something's amiss with objtool. But once the warnings are all gone, in my experience it means objtool's working well. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel