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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 36873C77B75 for ; Mon, 22 May 2023 19:59:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8AB128465A; Mon, 22 May 2023 21:59:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="iVUUqePX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id BD5DD84747; Mon, 22 May 2023 21:59:46 +0200 (CEST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4823482A2C for ; Mon, 22 May 2023 21:59:44 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=cfsworks@gmail.com Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-64d2c865e4eso3210288b3a.0 for ; Mon, 22 May 2023 12:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684785582; x=1687377582; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zrqFuT3k3L/+uUR9fVH91H/3UI3s5XBPoe2CSONUznI=; b=iVUUqePX6cmfpCJuHCnFqq3VJ2NsKIBdJ7FBn4/vr/oXlpeZf1zqL+cbW5YP7U1JSf OdKnP7iue2KT71c7bmXTza1VDDc7LpJxie6G08bsT5dGzFSoJrhIocLm3qOd8G2pArIu OTOnEXq1H8Zt4Y1svFAlX2tHSGp5Je5EUF0xQYH7fUBiFTbFrvYtorUrPVNgJ2nMJzI9 j23WtYBKseYOj9Qk0YqkNVWb2emOLdqNMs0n9tDWOH2szB0N1xCerIhZBQWvzqg04V+L 0yGRaD1FVNl/rqtspPAl3MqC3TTDOaj6PvmMqIsq30sK5ed9uMgtYYB4h5oPSCm7VKSZ p0qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684785582; x=1687377582; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zrqFuT3k3L/+uUR9fVH91H/3UI3s5XBPoe2CSONUznI=; b=IwGuPGyPast+8N4OFbnkTjkYdc+vF6guD0V1/Qh+FNhzk0JWjLtyf+3cC1EAsdi7dL JdGZ9epMbgk/DaV45xrjGoOUWjLTs7V4UEnSdRC8w4CIH3Ix1rRf2srn+CMwxaNeIX6s bnk0jgfE5b3Wl+BIQPHodjkcB3JYj7obh7UBMnqYGW3kubKyDYUvFIjZNjmJ6U6dXcYv aFHXj78qqKlKU3UAfN/KUKs1lzhgp+mNBPIX288tORTnOvEMQyCwDM+6yM8XRniR5dnH BM8g+ioAPbFJO5xE8uahiU5n+Axxrax8dNBXG7HffHTq/nDykCpTEcYMgYhanYmdf2WI gn6g== X-Gm-Message-State: AC+VfDzZfveRSkTnZl6E1UXj+KknalPYAcH2e7nUcFoky3eJHUxOQuQA Rgt0QkBlzzx/8c92fHdIW8E= X-Google-Smtp-Source: ACHHUZ5s3O2k24+dPs+F/X3Hx1ZEP262kDkpDdmHUXE2tqenNbkXEehhrmfAAKXGbIh/NBVUqT/bpw== X-Received: by 2002:a05:6a21:33aa:b0:10a:b2a2:a301 with SMTP id yy42-20020a056a2133aa00b0010ab2a2a301mr9265901pzb.12.1684785582235; Mon, 22 May 2023 12:59:42 -0700 (PDT) Received: from [10.64.107.252] (static-198-54-134-172.cust.tzulo.com. [198.54.134.172]) by smtp.gmail.com with ESMTPSA id j12-20020aa78dcc000000b0062de9ef6915sm4462440pfr.216.2023.05.22.12.59.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 May 2023 12:59:41 -0700 (PDT) Message-ID: <7640951a-8a3a-6747-52fb-ab19417e813f@gmail.com> Date: Mon, 22 May 2023 13:59:33 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain Content-Language: en-US To: Tom Rini , Michal Simek Cc: Heinrich Schuchardt , u-boot@lists.denx.de, Alper Nebi Yasak , Andrew Scull , Ilias Apalodimas , Kever Yang , =?UTF-8?Q?Marek_Beh=c3=ban?= , Nathan Barrett-Morrison , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Peng Fan , Philip Oberfichtner , Philipp Tomsich , Quentin Schulz , Simon Glass References: <20230520205547.1009254-1-CFSworks@gmail.com> <23EFB5F3-C3F5-44BC-BB6D-730656F67578@gmx.de> <2355e4a5-1474-5579-2171-8339226db14f@gmail.com> <35cdee04-e94c-0915-85cb-89fb0ea9a6d9@amd.com> <20230522153006.GD8649@bill-the-cat> From: Sam Edwards In-Reply-To: <20230522153006.GD8649@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Hi Tom, On 5/22/23 09:30, Tom Rini wrote: > I think objcopy is a bit of a stretch at this > point and it's not clear from the above if you're also making use of the > assembler. I agree, since getting llvm-objcopy to play nice with this currently requires that I make a handful of small hack edits to the makefiles. It does offer a great advantage over GNU's objcopy in that it doesn't balk at ELFs from a foreign arch, but I'm only supporting it "opportunistically" right now. I do make use of LLVM's assembler, but LLVM bundles its assembler inside the Clang binary (`clang -cc1as` and/or just pass .S files to Clang) rather than installing a separate program. This is not to be confused with `llvm-as` which is for bitcode/IR manipulation only. But in general, if you're using Clang, you're also using the LLVM assembler. > We might also want to look at backporting > scripts/Makefile.clang from the current kernel build system and then > adapting the "guess the --target argument" logic based on CONFIG_$ARCH > rather than ARCH= (which we don't use). That would also solve the LTO > problem as that's a result of us missing some flags that the kernel has > as LLVM+LTO (logically) requires LLVM LD not GNU LD. Having something like Linux's `LLVM=1` to enable LLVM would be ideal, I think. I probably won't be doing that backporting in this patch series since my goal for now is just to fill in some of the pitfalls for people like me who are too stubborn to install a GNU toolchain. > At that point, and once the EFI guid_t warning is resolved to everyones > satisfaction we can put qemu_arm* + clang in the CI loop, to catch new > warnings there. I've already got clang + Pi in my CI loop, but that > doesn't fail on warnings. Do you mean, on the current master branch, and only Clang (no LLD)? I'm in favor, but since a few of the patches in this series (#3-5) are to support some of the libcalls that LLVM's codegen likes to emit, I'd be surprised if that worked on all targets. Feel free to pull whatever necessary patches of mine here into your own series though. :) Cheers, Sam