Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1326171ybh; Thu, 23 Jul 2020 06:17:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLkxC72NtTHl0MLnsc9OGOl3E1LIxOxSYoYq7qCPIdjLOVaupth52NZlXFDzAdV7HhBzeU X-Received: by 2002:a17:906:57c6:: with SMTP id u6mr4291179ejr.194.1595510240996; Thu, 23 Jul 2020 06:17:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595510240; cv=none; d=google.com; s=arc-20160816; b=iZ+uISIW9/ijuFuWqu847hAdBEHVkMtudn3+IZ3l2H7kr/9/nccjrctUo9WJJn0ClN 7inNL+j9tQY3Pa0bloCpDlzq+3FLx8e4pXRQuzhWi7J87ec7EkiLJkz+5mNhxV+4aNDT AxmxjEbavx/3gCwGKfdWbUqaoh9P9YqqukZaojs3wdztxwr3/5qMikUiO6bqYgLNN7Vv TywlXPNatm4eWTMrOdBjSsdhlTBVFeNtPMzaWv4QYIFZV1pd/3NQK8SX+l8ydIW0HWCR LCOjF7lfqsSBfrvhGgO80p2RVXVX9eE0/vbs8/H2o3vhuEmghoXjHCfMdIwZagfo53xg CEJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=32lEAPZ/UL3cKAISqUdZsL9ffI08w61Ejr7d1duZqTc=; b=MDGnE3FKigKo0QLL8Q2z6rkFlMRp1kGK4jTSLYn5O44dAVPHQCDCQkkmJBLKmKP8bQ TpeURrbvoXsjV+riKBYgFH1g6dzv88g6slPY8ndqJmzoTjjkJICzeTQgO7ZpmkqUzWW7 gohhiwME2byd3ZqNWYmjKPdbD/9xzXEVxhlST3azM4PJRbbsHHnzxdtUuyVdlKEivH14 vwGgVGIpFCmhs4LDjL3YFygxprWPlrlYk0Hw2t9io4pjaWr/u/nstfWi+znqFWHgHT19 2OkIpdJvG/H6a7SOTOqHc54CwDwsugMl7Ouh0IJrf9jeJkquMPOwc3WvU4aAQzffoCNr FIgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ezgb8FZM; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 17si1851112ejw.686.2020.07.23.06.16.58; Thu, 23 Jul 2020 06:17:20 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=Ezgb8FZM; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729292AbgGWNOQ (ORCPT + 99 others); Thu, 23 Jul 2020 09:14:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726521AbgGWNOP (ORCPT ); Thu, 23 Jul 2020 09:14:15 -0400 Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35E7FC0619DC for ; Thu, 23 Jul 2020 06:14:15 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id a12so6130384ion.13 for ; Thu, 23 Jul 2020 06:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=32lEAPZ/UL3cKAISqUdZsL9ffI08w61Ejr7d1duZqTc=; b=Ezgb8FZMVXOpoMijXt1qft0zJOhUWa1bXDnBvoMPOzuiuO0TLV4IDy4HlOifHZM29Y Xyj7XI7dGPpirUmwX74Da1425iGl7i5wwAErhRVwnbIS54EOpgeEaPGeSyiJWhkjSvPF FCXyh7rOAfBk7GNmaqwhUhbj/tS/rjaNTo2m/QYgvRNS2icFG09ZaSxcdoP6Wplw8MC6 f2gK34zRbLATKH3SJMpTISHp7AYS4zZ/zz2x7S50grogE/xJTY3NaP/Dkkh/p6fCMGQS jPhTU/8LQ6BjdP4UMGveSjNJ/SRwMq+Xh17NY0aRSddG4GBGKy8vABttvzIZjKMbZlT9 +4cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=32lEAPZ/UL3cKAISqUdZsL9ffI08w61Ejr7d1duZqTc=; b=bg2KRSSkcuFdAOunBoyAGI8E6kr52ISl/m303RV2iyJoIrxvxuyrI528RrCq1Vqsir Y8snnZFr0IneET2PmqMUfTiC2TKkJiXZ4dpYTU1bRza8UD/Gxhh+hA3xDJHq3VQtR9UM kMK++zY/8B2pWdqSK6HHo7Kd/UUddzY2SOr4yufdZjimcEsY4uTCjpVIXOWEtQzhjCTL O5VptsqWfCLDZFR2YfjystGoJIWAf8HhCO3IDKML+E7NfotZDDFT5S10BukMoZ77c3mb SE5qg4r82Mceh9N+lZFJ/hsdm4BXjq+yBvPBLUUDv7N4+alsTeSmixQzAxJ2qPwQ3UR6 +EFQ== X-Gm-Message-State: AOAM532I5/HOQY2IZOOU5dzWPmbYDZvKPgnY3jmvoacDb3xn0eMwmQbs qRHqYKdqcjYqLys+LD4xWfoR/E7tw/9jJoZJuZI= X-Received: by 2002:a05:6602:1555:: with SMTP id h21mr4813840iow.163.1595510054602; Thu, 23 Jul 2020 06:14:14 -0700 (PDT) MIME-Version: 1.0 References: <20200720204925.3654302-1-ndesaulniers@google.com> <20200720204925.3654302-12-ndesaulniers@google.com> <87365izj7i.fsf@nanos.tec.linutronix.de> <87zh7qy4i4.fsf@nanos.tec.linutronix.de> In-Reply-To: Reply-To: sedat.dilek@gmail.com From: Sedat Dilek Date: Thu, 23 Jul 2020 15:14:02 +0200 Message-ID: Subject: Re: [PATCH v3 11/11] x86: support i386 with Clang To: Arnd Bergmann Cc: Thomas Gleixner , Nick Desaulniers , Ingo Molnar , Borislav Petkov , Dennis Zhou , Tejun Heo , Christoph Lameter , "the arch/x86 maintainers" , "H. Peter Anvin" , Al Viro , Andrew Morton , Peter Zijlstra , "linux-kernel@vger.kernel.org" , Clang-Built-Linux ML , David Woodhouse , Dmitry Golovin , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 23, 2020 at 1:42 PM Arnd Bergmann wrote: > > On Thu, Jul 23, 2020 at 1:07 PM Sedat Dilek wrote: > > On Thu, Jul 23, 2020 at 11:17 AM Thomas Gleixner wrote: > > > Thomas Gleixner writes: > > > > I have applied this patch-series v3 but some basics of "i386" usage > > are not clear to me when I wanted to test it and give some feedback. > > > > [1] is the original place in CBL where this was reported and I have > > commented on this. > > > > Beyond some old cruft in i386_defconfig like non-existent > > "CONFIG_CRYPTO_AES_586" I have some fundamental questions: > > > > What means "ARCH=i386" and where it is used (for)? > > > > I can do: > > > > $ ARCH=x86 make V=1 -j3 $MAKE_OPTS i386_defconfig > > $ make V=1 -j3 $MAKE_OPTS i386_defconfig > > > > ...which results in the same .config. > > > > Whereas when I do: > > > > $ ARCH=i386 make V=1 -j3 $MAKE_OPTS i386_defconfig > > > > ...drops CONFIG_64BIT line entirely. > > > > But "# CONFIG_64BIT is not set" is explicitly set in > > arch/x86/configs/i386_defconfig but gets dropped. > > > > Unsure if above is the same like: > > $ ARCH=i386 make V=1 -j3 $MAKE_OPTS defconfig > > The logic was introduced when arch/i386 and arch/x86_64 got > merged into arch/x86, to stay compatible with the original behavior > that would produce a 32-bit or 64-bit kernel depending on which > machine you are running on. > > There are probably not a lot of people building kernels on 32-bit > machines any more (real 32-bit machines are really slow compared > to modern ones, and 64-bit machines running 32-bit distros usually > want a 64-bit kernel), so it could in theory be changed. > > It will certainly break someone's workflow though, so nobody has > proposed actually changing it so far. > > > When generating via "make ... i386_defconfig" modern gcc-9 and and a > > snapshot version of clang-11 build both with: > > > > $ ARCH=x86 make V=1 -j3 $MAKE_OPTS > > ... -march=i686 -mtune=generic ... > > > > Checking generated .config reveals: > > > > CONFIG_M686=y > > > > So, I guess modern compilers do at least support "i686" as lowest CPU? > > i686 compiler support goes back to the 1990s, and the kernel now > requires at least gcc-4.9 from 2014, so yes. > > > Nick D. says: > > > I usually test with make ... i386_defconfig. > > > > Can you enlighten a bit? > > > > Of course, I can send a patch to remove the "CONFIG_CRYPTO_AES_586=y" > > line from i386_defconfig. > > The "i386" in i386_defconfig is just a synonym for x86-32, it does not > imply a particular CPU generation. The original i386 is no longer supported, > i486sx (barely) is and in practice most 32-bit Linux code gets compiled > for some variant of i586 or i686 variant but run on 64-bit hardware. > Thanks a lot Arnd for all the detailed informations. A change of i386_defconfig to x86_defconfig will cause a big cry from all kernel-bot maintainers :-). - Sedat - P.S.: CONFIG_64BIT What I dropped by accident in my previous mail: What happens when there is no CONFIG_64BIT line? There exist explicit checks for (and "inverse") of CONFIG_64BIT like "ifdef" and "ifndef" or any "defined(...)" and its opposite? I remember I have seen checks for it in x86 tree. - EOT -