Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2366307pxb; Sat, 27 Feb 2021 21:58:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJzm7d36m0b+9e+jmLmxZPoqBMcSoV/PScsKzEnFZU6aG0aZdzA4PbSbr3eu91J66HBmQWNe X-Received: by 2002:a05:6402:c15:: with SMTP id co21mr10798182edb.115.1614491908175; Sat, 27 Feb 2021 21:58:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614491908; cv=none; d=google.com; s=arc-20160816; b=oUUB5k2lJ7V6DS415mBb1J2InWVDBHVeZsZTVyd99eyj39tlJix9UL5qBIgZVbVjTo 3SVTQF3bSZdwBJV9RaCJucE7d6Hid92qEM39ONfWi8BbL6U/WRW/F5D4U+QVV5oqJpgB Py1+CBzyOAfP75qooCNB0IRXUYwhSnPYvoiqNKU6RCMeSt3MWoDMnAtz1l+3Z3ubNAuf nKJFINgypEUEs8P5J/VjtvffOqHqfYCFnjiCn+GD1v0lCHpB8fLoyycBOfeg0w3zfmdw XqqpzYQi6IqYFLTfHW/hEKlxg9SL6ryInAYmJNVZ3eySKYkH9oB/QQE1BGlUjjv4we5o sqSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=fIHDClkBpaMvFoqSPfjj0EmUE/3x09RJqK+wtPPSg4Y=; b=Ehu3krlxmKSfW0I+DyEDQtyjTMxrnSiAbGmN499JPK7eG1ds1l2d7AwTX3jeoM0l/j C72XSir76E43urNIL/IaKreiprFSzTOanrnHQakzKgqoCCLDR4KoIVkn1AlAn118OpgC a008bw9uOH2K0SsNcoIMRcFGoOla8LkTB0nvN6c8Fw3lbeuLcHmvZENWVDisK19L2WES niYGlNrjJsOtabwLqZbcfSx13FhNaYTbDhG8e321IUXx1dZSpCYP0cZlEjZ5GIBF9HwY EhFb98EMXyF+RrSLnGH3AH8MNeFUGb3Ws2NrlDB3Ak0R8bKoIr8OtuKdx+SpcI1PvtBq +lYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rKUY1oh2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si8779508edp.42.2021.02.27.21.58.03; Sat, 27 Feb 2021 21:58:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rKUY1oh2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230107AbhB1FwU (ORCPT + 99 others); Sun, 28 Feb 2021 00:52:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbhB1FwN (ORCPT ); Sun, 28 Feb 2021 00:52:13 -0500 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 041EDC06174A for ; Sat, 27 Feb 2021 21:51:32 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id r5so9003154pfh.13 for ; Sat, 27 Feb 2021 21:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fIHDClkBpaMvFoqSPfjj0EmUE/3x09RJqK+wtPPSg4Y=; b=rKUY1oh245LhQvch6JWVGDf6a4r6pxSBfM0feGDNwBeQvC4sHH2+C8P8yMMRa2hRDb 2Z430wMWNJQsZ/TQbnnJDxA8cG9oKE9/zR+53fRudHo7pYUZRMxXt/jj3TQdUbKFY2/S Int/xQmCCvFRLcUk2N5NCIefgHmfwWU+CM+MccAzfAi/q/tsM34pKZrUrctvjunALRsb wGb+fEbPb9QcX0ISVMC8Wv6wDWL+WTl0+H7PhJkgApwe/t7FM8WwmrQW6njmo/1wJCV6 ttUUtGrUXs9bTWLCczPVZ3MzUkec/qnNWVhD9zIGQmdcZlAU+BFTraBeqhNoRrlZ6+D9 +Zmw== 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=fIHDClkBpaMvFoqSPfjj0EmUE/3x09RJqK+wtPPSg4Y=; b=BDxtpeT1Qp9M+uyenKe7a7YpZVFECgGtZntduVoK6f5OEJGjb/jaVXuTBccUcDPI7n Ja+VqPr6VkliMPoATasG6SbWyEN0GcuPOMzqQ7fDj5/UNdlMOl1bWJPJQ/JTGL41x1Gl /6MWFZ+s52HGZOcaK80qFE7OIPbUHRhYmt1a2kgAGBwlSBWMf0Ou7WNQrdWZwo94soi9 MFJanzDmFjZ2ZTd/Y6dl4ytzu7VkPTUUpcQrz56LSUXCbPX8VWmqMeuFLnQuCxK8jopc /ChIkWaXwMoekLGeC8WSYaBTISB/QXkzyuh2kiupws8vHYyxLWCYDGDRKAH7iyQh21H3 S6xw== X-Gm-Message-State: AOAM533HdAx0/FRMJEGwtOLDncc/a3wx3GA0K5/KdfQD7PyIPOWVa0xK BU9hs4egs9KKWU9CSj7zjCRLvA== X-Received: by 2002:a63:c601:: with SMTP id w1mr3085474pgg.11.1614491490896; Sat, 27 Feb 2021 21:51:30 -0800 (PST) Received: from google.com ([2620:15c:2ce:0:cd02:8b49:9326:693e]) by smtp.gmail.com with ESMTPSA id l22sm3715072pjy.51.2021.02.27.21.51.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Feb 2021 21:51:30 -0800 (PST) Date: Sat, 27 Feb 2021 21:51:24 -0800 From: Fangrui Song To: Masahiro Yamada Cc: x86@kernel.org, Thomas Gleixner , Borislav Petkov , "H . Peter Anvin" , Peter Zijlstra , clang-built-linux@googlegroups.com, "H . J . Lu" , Andy Lutomirski , Arnd Bergmann , Brian Gerst , "Chang S. Bae" , Chao Yu , "Darrick J. Wong" , Dmitry Safonov <0x7f454c46@gmail.com>, Dominik Brodowski , Gabriel Krisman Bertazi , Ingo Molnar , Jaroslav Kysela , Jason Gunthorpe , Jethro Beekman , Kees Cook , Miklos Szeredi , Nathan Chancellor , Nick Desaulniers , Sasha Levin , Sean Christopherson , Takashi Iwai , alsa-devel@alsa-project.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability Message-ID: <20210228055124.sj3z5n3o5y4w54au@google.com> References: <20210227183910.221873-1-masahiroy@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210227183910.221873-1-masahiroy@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-02-28, Masahiro Yamada wrote: >This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than >error if binutils too old"). > >The help text in arch/x86/Kconfig says enabling the X32 ABI support >needs binutils 2.22 or later. This is met because the minimal binutils >version is 2.23 according to Documentation/process/changes.rst. > >I would not say I am not familiar with toolchain configuration, but >I checked the configure.tgt code in binutils. The elf32_x86_64 >emulation mode seems to be included when it is configured for the >x86_64-*-linux-* target. > >I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO. > >I removed the compile-time check in arch/x86/Makefile, in the hope of >elf32_x86_64 being always supported. > >With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent. >Rename the former to the latter. Hi Masahiro, the cleanup looks nice! As of LLVM toolchain support, I don't know any user using LLVM binary utilities or LLD. The support on binary utitlies should be minimum anyway (EM_X86_64, ELFCLASS32, ELFDATA2LSB are mostly all the tool needs to know for many utilities), so many of they should just work. For llvm-objcopy, I know two issues related to `$(OBJCOPY) -O elf32-x86-64` (actually `objcopy -I elf64-x86-64 -O elf32-x86-64`). Such an operation tries to convert an ELFCLASS64 object file to an ELFCLASS32 object file. It is not very clear what GNU objcopy does. llvm-objcopy is dumb and does not do fancy CLASS conversion. * {gcc,clang} -gz{,=zlib} produced object files. The Elf{32,64}_Chdr headers are different. Seems that GNU objcopy can convert the headers (https://github.com/ClangBuiltLinux/linux/issues/514). llvm-objcopy cannot do it. * Seems that GNU objcopy can convert .note.gnu.property (https://github.com/ClangBuiltLinux/linux/issues/1141#issuecomment-678798228) llvm-objcopy cannot do it. On the linker side, I know TLS relaxations and IBT need special care and I believe LLD does not handle them correctly. Thankfully the kernel does not use thread-local storage so this is not an issue. So perhaps for most configurations it is already working. Since you've tested it, that is good news to me:)