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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 6FC1DC433E0 for ; Tue, 9 Mar 2021 14:29:46 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 CAFCF6519C for ; Tue, 9 Mar 2021 14:29:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAFCF6519C 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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=357UEkmcadU94KkbC1hhw2vWiP+wbBSSLKQJMRXK+DY=; b=QYyUOgDbK3anhitCdGas6lKXh ixeM7NEIzKG8cgdv3+v4w3MZXI2lBO7hpSMOMXMM0n1VE0JYXl6/duaLFReyw1tu5O559TQardkzd 296QdcF59hackcC1z9ypZHu8E69Ui87ipxgj4ELKdjcEkgbWxD+Vecl85ag+hOMh4Tf6QkUcgpcZN lRAMWikXoGwo+OZ/WvsMV8wtcmOM4sUKkWjK8+3/AYFvj79q2BNf5O9g9O8NTpeBoAgfRnZ0HdqLl naRt0V2Bc9AI2kCLxTbwWdO7skgztwxXMuPdHX6mqW4XRIk8yk+abxUP9EAttM9XC9ZnENvpFspPY Ys+zKFxjg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJdKo-004q34-Sj; Tue, 09 Mar 2021 14:27:43 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJdKg-004pzk-HI for linux-arm-kernel@lists.infradead.org; Tue, 09 Mar 2021 14:27:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615300051; 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=uefc69ZAVo40Lyi9qS15enKlYyR1TmA5w4KWE/8N6f0=; b=KUlbxgZ0M2POA5+o0w4f/znMs2+JDkuhIa9wl0sGMRdFZoCSKyRXDITQ8AvANf88H1rjA3 3inyBwINYXh4uy2iEGyPDQu1kRIsxwg8eqsXBS+nnEdgOwU26EDxzENQ+ZBmTWVVM4dlG8 gM1LeZ3PY3msP94TUl1SQuxWTMwAJ7g= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-390-zScxZW_DNbma4Ep9wA3-IA-1; Tue, 09 Mar 2021 09:27:29 -0500 X-MC-Unique: zScxZW_DNbma4Ep9wA3-IA-1 Received: by mail-wr1-f69.google.com with SMTP id e29so6506334wra.12 for ; Tue, 09 Mar 2021 06:27:29 -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=uefc69ZAVo40Lyi9qS15enKlYyR1TmA5w4KWE/8N6f0=; b=dNY5kPN5X88beWHtAaBhMX05kJWd3RjCTlPp1mhgDJd7ahf+XDwYxRj4MHhqdXoBtP ZjfsSwpQ8gvaX+71Kgtp1jGJpTU/2c5PKxjosrTt8PNbERjlfP4suFf1Gf57RQbNC7n4 QrhWct0ExYBHU80KNOJxnvLKHk/ktnikQGlYCDwVMkXvV5yNCP1sh2msEv24hPpIUq3N r/exTmmpRyAzoHaQTwLhdUXimNkZ6/T5Wpro370y9ZOW18lLFz+Y+OYRq+8rdoseOu2f CzlplnmRGSPBbNjIUxDKjyGG/Fp0GqfCtc4oFsB3A44O3jZ/Ul92aXZ2mPVFM1e90h/U +6Ww== X-Gm-Message-State: AOAM533tKqh/hw0qskchfNJ9wU2mOdWP/fmS0SvcUJAuRtXT9gr71rBk 3qXttz3QUwveaQ+qZdifh+8qOxi/MOqBC+BAQSvmbBrh0dfV05KuC4mB5ZqJZ1MYCz2jbSeUmiZ BHKkgld4XbHLjFwZMwQFC8IqlLdVv4/t0Jdo= X-Received: by 2002:a1c:a5c7:: with SMTP id o190mr4437939wme.172.1615300048129; Tue, 09 Mar 2021 06:27:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJziYLcxKgKhST0pV5HkhnHk/u+COVI1jyY3xXYJj71+XW5C6Uppli/1zbPdoQUMgPjx5kTHHw== X-Received: by 2002:a1c:a5c7:: with SMTP id o190mr4437912wme.172.1615300047976; Tue, 09 Mar 2021 06:27:27 -0800 (PST) Received: from ?IPv6:2a01:cb14:499:3d00:cd47:f651:9d80:157a? ([2a01:cb14:499:3d00:cd47:f651:9d80:157a]) by smtp.gmail.com with ESMTPSA id o7sm23869752wrs.16.2021.03.09.06.27.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Mar 2021 06:27:27 -0800 (PST) Subject: Re: [RFC PATCH v2 00/13] objtool: add base support for arm64 To: Nick Desaulniers Cc: Ard Biesheuvel , Catalin Marinas , Josh Poimboeuf , Linux ARM , LKML , Mark Rutland , Masahiro Yamada , Peter Zijlstra , Will Deacon , ycote@redhat.com, Fangrui Song , Bill Wendling , Pete Swain , Yonghyun Hwang , clang-built-linux References: <20210303170932.1838634-1-jthierry@redhat.com> <20210305235102.384950-1-ndesaulniers@google.com> From: Julien Thierry Message-ID: <47cb7299-a361-6036-fc6e-860bbcfc2476@redhat.com> Date: Tue, 9 Mar 2021 15:27:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jthierry@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210309_142734_792438_18962A17 X-CRM114-Status: GOOD ( 26.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/6/21 1:04 AM, Nick Desaulniers wrote: > On Fri, Mar 5, 2021 at 3:51 PM Nick Desaulniers wrote: >> >> (in response to >> https://lore.kernel.org/linux-arm-kernel/20210303170932.1838634-1-jthierry@redhat.com/ >> from the command line) >> >>> Changes since v1[2]: >>> - Drop gcc plugin in favor of -fno-jump-tables >> >> Thank you for this! I built+booted(under emulation) arm64 defconfig and built >> arm64 allmodconfig with LLVM=1 with this series applied. >> >> Tested-by: Nick Desaulniers >> >> One thing I noticed was a spew of warnings for allmodconfig, like: >> init/main.o: warning: objtool: asan.module_ctor()+0xc: call without frame pointer save/setup >> init/main.o: warning: objtool: asan.module_dtor()+0xc: call without frame pointer save/setup >> >> I assume those are from the KASAN constructors. See also: >> https://github.com/ClangBuiltLinux/linux/issues/1238 >> >> Can we disable HAVE_STACK_PROTECTOR if CC_IS_CLANG and CONFIG_KASAN is set, >> until we can resolve the above issue? So that concerns objtool for all arches, right? > > Ah, filtering the logs more, it looks like GCOV is has the same issue > KASAN does (known issue). Here's a filtered log: > https://gist.github.com/nickdesaulniers/01358015b33bd16ccd7d951c4a8c44e7 > > I'm curious about the failure to decode certain instructions? > This is probably related to data constants present in code sections. To fix this, objtool needs to handle SYM_DATA_* annotations [1] and then the relevant bytes need to be annotated in the kernel sources (e.g. [2], but there are multiple parts in arm64 assembler needing this). I have not submitted those yet because I didn't want the amount of patches to become overwhelming and mixing objtool + kernel sources. [1] https://github.com/julien-thierry/linux/commit/9005e9f3bb10aac663c42bb87d337b7a1aae5a67 [2] https://github.com/julien-thierry/linux/commit/ad132b032b4141c7ffce95d784b5254120e5bf65 > The stack state mismatches are what are valuable to me; we'll need > some help digging into those at some point. The logs from defconfig > are clean. > I think at the moment this is mostly a limitation of objtool to track code flow. aarch64 code tends to do a lot more register load/store inside a function than x86, and objtool doesn't track multiple register states (e.g. a registered stored at some offset on the stack at the beginning of the function, and later at some other stack offset). Although, when looking at the disassembled code, I'm not 100% I understand why there are so many intermediary store/load for these registers since it doesn't look like those values are actually used (I don't know whether this is caused by kasan/probes instrumentation). But I'd need to investigate a bit more. -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel