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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 653D1C433DF for ; Tue, 11 Aug 2020 15:06:27 +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 3419020771 for ; Tue, 11 Aug 2020 15:06:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="byQhbArs"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="NkBBpgk+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3419020771 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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=cMjfRRZkjfg700BsH3SJRuPXM/szhJ+yYnrS2Ywx4tY=; b=byQhbArs9wRyVMTzHoNmbpNwg +UXwsETwXb2Iy8XpeI7oJtmC2Y5vnmudDs2j6EovFwXqAAOdK6nhm4WcmGG33wV/2TYIau7fKSrg8 yQRbojvkhAT5vdZcVVL5W60yAOkUyezEmQtRt6I4grFRdU9Tpet5gg6txnrEyL5mjFvlak3nkm/EZ ji8Y/NkcADFrkia9FLVZMQwyOzPHrmVLd5q9QD5Gy2Pq7SBl2GH1t36brISs8SlkGA8YSc2vihN5b um7QFsP3ikqd3SDrPe9EqCm6p0CWYIwhqibhiF7sleJ+MILz9sJeezIFJHP2RIPRiqtD6HlMN6AcR oRa2r6VkQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5Vpn-0002gy-RH; Tue, 11 Aug 2020 15:05:03 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5Vpk-0002fu-GD for linux-arm-kernel@lists.infradead.org; Tue, 11 Aug 2020 15:05:02 +0000 Received: by mail-ed1-x542.google.com with SMTP id bs17so9344933edb.1 for ; Tue, 11 Aug 2020 08:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KKqkSO4E1uS1b2bksCXs/o+nKhlCAG7ZBaNsab2Ulgs=; b=NkBBpgk+jTFT2aFNFY5+mnvKbmcOXWPJOYWmYUD3JCmRDe2KXKwqjVSuBms6+mcmOi fIpnu1goC7yN2WkiKwaiAyz9Vu6wbf6BYro0Mu1GQZj94kk1NhdTKe+eMFSIQlbTIgef 9odrYQYzsTeRiANXlVuGJ/6RVaCX99wMTOSPvbYrsvJBLOHPCxRhxvPcLIfLi5heeqcY YoG1BDUe0uXehvpYq1l00poChcyB14NY3GAvptAEAYv1BGMBK1hz18/7NDsHcEGTIdHq G0sM3wg6A6VUC35lOW8cE0YQNJ98v372T7ThcoXpe6wxMD7kxB99vkZlMFsYZozbvKUW h0Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KKqkSO4E1uS1b2bksCXs/o+nKhlCAG7ZBaNsab2Ulgs=; b=Wq+xjKNVwmULwLu5B2iKpF916Jy4/WGnUFShgpy0aCfAzMfvUm0lHjaX7H9BrFE3Ex sFvGQ3TnCVssyjL2PXtw+JhP7zLxy6Xa0klxmbEF9b/UaOt1ffDStG2NnTns9NxotL4D NGdnVdhtVXFKL6DiQOWhPFKHpS3YONBsdVs/18kyzLPJXTNwrkx03bMtTQlYeKwsyEsy S6fzu9pYI4ctkKRhg/F+yY1muMfu18gwYIrHddq3rToAQ2+PHKkjX2U4UKyK/yZMeK99 D3aK3KjZh4Ciq0UPVc3kzK8GY+njwWjubwSnKT8261Wgmb37mpDAXYMDEOvjW70a7vFe r3rg== X-Gm-Message-State: AOAM532jOt11Z2041opokDBqwrZ+umqkfBdM0ODDcW9VeOntrd+YpIHl m6G7aBTGMGWXgHpHKJN1y5thDw== X-Google-Smtp-Source: ABdhPJyFs95sbQHJP7jqePYuXjzQy0pv/UF/rdTUlZtJwMFXhtBTRvfUqKJKJJBdi5D4djEyXrjFgQ== X-Received: by 2002:aa7:cd04:: with SMTP id b4mr25690140edw.254.1597158297623; Tue, 11 Aug 2020 08:04:57 -0700 (PDT) Received: from myrica ([2001:1715:4e26:a7e0:116c:c27a:3e7f:5eaf]) by smtp.gmail.com with ESMTPSA id x1sm15015473ejc.119.2020.08.11.08.04.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2020 08:04:56 -0700 (PDT) Date: Tue, 11 Aug 2020 17:04:41 +0200 From: Jean-Philippe Brucker To: Daniel Borkmann Subject: Re: [PATCH bpf] libbpf: Handle GCC built-in types for Arm NEON Message-ID: <20200811150441.GA3033213@myrica> References: <20200810122835.2309026-1-jean-philippe@linaro.org> <65afcc0c-5468-1654-83d6-dade2c848745@iogearbox.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <65afcc0c-5468-1654-83d6-dade2c848745@iogearbox.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200811_110500_880002_69B8CC74 X-CRM114-Status: GOOD ( 25.80 ) 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: songliubraving@fb.com, Jakov Petrina , john.fastabend@gmail.com, ast@kernel.org, kpsingh@chromium.org, yhs@fb.com, bpf@vger.kernel.org, andriin@fb.com, kafai@fb.com, 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 Tue, Aug 11, 2020 at 04:10:31PM +0200, Daniel Borkmann wrote: > On 8/10/20 2:28 PM, Jean-Philippe Brucker wrote: > > When building Arm NEON (SIMD) code, GCC emits built-in types __PolyXX_t, > > which are not recognized by Clang. This causes build failures when > > including vmlinux.h generated from a kernel built with CONFIG_RAID6_PQ=y > > and CONFIG_KERNEL_MODE_NEON. Emit typedefs for these built-in types, > > based on the Clang definitions. poly64_t is unsigned long because it's > > only defined for 64-bit Arm. > > > > Including linux/kernel.h to use ARRAY_SIZE() incidentally redefined > > max(), causing a build bug due to different types, hence the seemingly > > unrelated change. > > > > Reported-by: Jakov Petrina > > Signed-off-by: Jean-Philippe Brucker > > Looks like this was fixed here [0], but not available on older clang/LLVM > versions, right? > > [0] https://reviews.llvm.org/D79711 No, that issue is unrelated. Here the problem is with the DWARF information generated by GCC. In Linux, lib/raid6/neon.uc uses poly8x16_t, and the DWARF information provided by GCC for that type uses a base type named "__Poly8_t", which is only understood by GCC. So after transforming DWARF->BTF->vmlinux.h, the generated vmlinux.h uses this "__Poly8_t" without typedefing it to unsigned char. Passing this vmlinux.h to GCC works because GCC recognizes "__Poly8_t" as one of its internal types, but passing it to clang fails: test.h:20:9: error: unknown type name '__Poly8_t' typedef __Poly8_t poly8x8_t[8]; ^ On the other hand a kernel built with Clang will have DWARF information that defines poly8x16_t to be an array of 16 unsigned char. > [...] > > +static const char *builtin_types[][2] = { > > + /* > > + * GCC emits typedefs to its internal __PolyXX_t types when compiling > > + * Arm SIMD intrinsics. Alias them to the same standard types as Clang. > > + */ > > + { "__Poly8_t", "unsigned char" }, > > + { "__Poly16_t", "unsigned short" }, > > + { "__Poly64_t", "unsigned long" }, > > + { "__Poly128_t", "unsigned __int128" }, > > In that above LLVM link [0], they typefdef this to signed types ... which one > is correct now? > > // For now, signedness of polynomial types depends on target > OS << "#ifdef __aarch64__\n"; > OS << "typedef uint8_t poly8_t;\n"; > OS << "typedef uint16_t poly16_t;\n"; > OS << "typedef uint64_t poly64_t;\n"; > OS << "typedef __uint128_t poly128_t;\n"; > OS << "#else\n"; > OS << "typedef int8_t poly8_t;\n"; > OS << "typedef int16_t poly16_t;\n"; > OS << "typedef int64_t poly64_t;\n"; > OS << "#endif\n"; I don't know why they typedef it to signed types on non-64bit, perhaps legacy support? The official doc linked in [0] (https://developer.arm.com/docs/101028/latest) states that they are unsigned: "poly8_t, poly16_t, poly64_t and poly128_t are defined as unsigned integer types." Thanks, Jean > > +}; > > + > > +static void btf_dump_emit_int_def(struct btf_dump *d, __u32 id, > > + const struct btf_type *t) > > +{ > > + const char *name = btf_dump_type_name(d, id); > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(builtin_types); i++) { > > + if (strcmp(name, builtin_types[i][0]) == 0) { > > + btf_dump_printf(d, "typedef %s %s;\n\n", > > + builtin_types[i][1], name); > > + break; > > + } > > + } > > +} > > + > > static void btf_dump_emit_enum_fwd(struct btf_dump *d, __u32 id, > > const struct btf_type *t) > > { > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel