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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 A5ABEC33CAB for ; Mon, 13 Jan 2020 07:58:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 71AEE2082E for ; Mon, 13 Jan 2020 07:58:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FrBSRObi"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Geq4fPqC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71AEE2082E 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+infradead-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=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xU9deNfiSXN0wlUXp0nE7ZiLi9Pk9lPAkTEGULB7Fds=; b=FrBSRObiWSN5PPPk87FxGLr0h /3326JhXs7cNQ6kQ7eO6a0EKov1rhC05ZRNuA5x6S02UJzi/S3RgSRtkCUT0pUqrsb3cW5o5zJHfq CQ7TkfwBm0Mzkb4myu/1W9T4xySmXNWWyYimlFHxtKYbZF0g3tXo9+9L2j5uN+Y3NsyLKP0zcnX1H +XB8xbNAu8e0X61OwSxrZ8k//kncubRlme7F7hm4x+f7RyRrxogMWzI8cjE++1dn3weUjlI/Oc0Im hisnF1UzhrbFSSoBPKxyH+5ub6de+4K16MO/ZM51st1JmNYBlTP0zAawr/hGW4UUmu5qpW0j9FChi EzoKpTLcA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqubp-0000lC-QA; Mon, 13 Jan 2020 07:58:01 +0000 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120] helo=us-smtp-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqubl-0000kA-Vq for linux-arm-kernel@lists.infradead.org; Mon, 13 Jan 2020 07:58:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578902275; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WRCNtJBa3pAnVzkWFvQcFj8dlg5Kh5b/Y+kQmy5E3UE=; b=Geq4fPqC+o7FoYQzUEo8bOv1L0MdL8rcYKGbmIsDLuMPF1kBRCqYHsq2evQXk3cC5tqB0K GlFVPZgKREOZWOLxppLqVYAjA/v6KsT7GvJrrzbKrI3rnU5Psnu7PRIOzCDHlpvaDzHbpY C5RNEQhJl1CJSxWReOAaYcXujTop8cM= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-172-1qeJX8E6PaCTdRwlcbUkfA-1; Mon, 13 Jan 2020 02:57:52 -0500 Received: by mail-wm1-f72.google.com with SMTP id f25so2239246wmb.1 for ; Sun, 12 Jan 2020 23:57:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WRCNtJBa3pAnVzkWFvQcFj8dlg5Kh5b/Y+kQmy5E3UE=; b=BsZgH5yqwkYBmoHyA2zL8d1/PmdmG4j6r9r6AeLPYlNKkg0sU6NOh07pIO/5dzkdux jdnzm+qsMXP84ixyqwGEyiQ9qfhV9aZO7xJ7Cjjbwh0fAjk8tk55WBOdzY99c3mj66E1 E8thpaYcVYO7XccRLjTe4ek0OVwYAqLWGaWeYAVsNirWVU2MAAcNcZ9bfW9ah4h3UK/d 6TtBjAsSFf2syRSVBoVvtkPgGQUKEVoZuXsEflcDwKOuTQz+HGzNRQUMfdsbgWokmGiP ezbBNfcpxW6jlO3Gup/Ln/AiWiho1XX40IK5P70LZpgq9N89dLE9BrPlAgicSHaySKbu 7azA== X-Gm-Message-State: APjAAAVplCrNR5A/LZnL1Oe8AEyDrw7QBam38rJT7R3ehFv6TRDerDPB IICTx+Ew+OEbP1j0fAs+rBgqcWCLew6djcWSbd9AUSWXJW87fYXpa7eW9TmIydwdMwHGTEUttiy r+LN1XPobplu/+W/geBiJ3369zVxILIqjbzc= X-Received: by 2002:adf:b193:: with SMTP id q19mr16871563wra.78.1578902271118; Sun, 12 Jan 2020 23:57:51 -0800 (PST) X-Google-Smtp-Source: APXvYqzqIhiJZej9sb5HxMulHntphAZP0eMI9QslhV7jkOwDAMQtJgRyF42O5Ld6R4wBUaye/bVyQA== X-Received: by 2002:adf:b193:: with SMTP id q19mr16871542wra.78.1578902270852; Sun, 12 Jan 2020 23:57:50 -0800 (PST) Received: from [192.168.1.81] (host81-140-166-164.range81-140.btcentralplus.com. [81.140.166.164]) by smtp.gmail.com with ESMTPSA id g18sm13034427wmh.48.2020.01.12.23.57.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jan 2020 23:57:50 -0800 (PST) Subject: Re: [RFC v5 00/57] objtool: Add support for arm64 To: Nathan Chancellor References: <20200109160300.26150-1-jthierry@redhat.com> <20200112084258.GA44004@ubuntu-x2-xlarge-x86> From: Julien Thierry Message-ID: Date: Mon, 13 Jan 2020 07:57:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200112084258.GA44004@ubuntu-x2-xlarge-x86> Content-Language: en-US X-MC-Unique: 1qeJX8E6PaCTdRwlcbUkfA-1 X-Mimecast-Spam-Score: 0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200112_235758_097880_2EB29527 X-CRM114-Status: GOOD ( 21.23 ) 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: peterz@infradead.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, raphael.gault@arm.com, jpoimboe@redhat.com, will@kernel.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Nathan, On 1/12/20 8:42 AM, Nathan Chancellor wrote: > > Hi Julien, > > The 0day bot reported a couple of issues with clang with this series; > the full report is available here (clang reports are only sent to our > mailing lists for manual triage for the time being): > > https://groups.google.com/d/msg/clang-built-linux/MJbl_xPxawg/mWjgDgZgBwAJ > Thanks, I'll have a look at those. > The first obvious issue is that this series appears to depend on a GCC > plugin? I'll be quite honest, objtool and everything it does is rather > over my head but I see this warning during configuration (allyesconfig): > > WARNING: unmet direct dependencies detected for GCC_PLUGIN_SWITCH_TABLES > Depends on [n]: GCC_PLUGINS [=n] && ARM64 [=y] > Selected by [y]: > - ARM64 [=y] && STACK_VALIDATION [=y] > > Followed by the actual error: > > error: unable to load plugin > './scripts/gcc-plugins/arm64_switch_table_detection_plugin.so': > './scripts/gcc-plugins/arm64_switch_table_detection_plugin.so: cannot > open shared object file: No such file or directory' > > If this plugin is absolutely necessary and can't be implemented in > another way so that clang can be used, seems like STACK_VALIDATION > should only be selected on ARM64 when CONFIG_CC_IS_GCC is not zero. > So currently the plugin is necessary for proper validation. One option can be to just let objtool output false positives on files containing jump tables when the plugin cannot be used. But overall I guess it makes more sense to disable stack validation for non-gcc builds, for now. Once people are happy with the state of things of arm64 objtool with gcc it might be worth looking at a clang plugin (although I don't know if the kernel has any support to build those at the moment). In the mean time, I'll do as you suggest and rely on CC_IS_GCC. > The second issue I see is the -Wenum-conversion warnings; they are > pretty trivial to fix (see commit e7e83dd3ff1d ("objtool: Fix Clang > enum conversion warning") upstream and the below diff). > Oh yes, these are valid warnings. I'll fix those. > Would you mind addressing these in a v6 if you happen to do one? > Yes, I'll most likely do one as I don't expect this to be a final version. Thanks for reporting those. I'll fix them in the next iteration. Cheers, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel