Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <892b6ab7-862c-1c0a-2996-0f8408e5043d@linux.ee>
 <89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de> <CAK7LNATuzry1MUj-VruOVUwU_nH2xJd_2SxD_s_Z1QBb3PVnQw@mail.gmail.com>
 <5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de> <CAK7LNATO_30uHzAe-Vsy+hgu=wwEN_aPGET4Ys78rc3=nSuJsg@mail.gmail.com>
 <YNOafsB81ZcP2r7z@ls3530> <f599c358-815f-088e-f2aa-b064ccb64e44@infradead.org>
In-Reply-To: <f599c358-815f-088e-f2aa-b064ccb64e44@infradead.org>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri, 19 Aug 2022 21:45:09 +0900
Message-ID: <CAK7LNAREcSW2Hn3Ty_zTVzTCLgYnFfo=ZcibE2zif1mBWp==4A@mail.gmail.com>
Subject: Re: linux-parisc compile failure in current git
To:     Randy Dunlap <rdunlap@infradead.org>
Cc:     Helge Deller <deller@gmx.de>,
        Parisc List <linux-parisc@vger.kernel.org>,
        Meelis Roos <mroos@linux.ee>,
        Linux Kernel Development <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Aug 18, 2022 at 5:59 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Hi--
>
> On 6/23/21 13:33, Helge Deller wrote:
> > * Masahiro Yamada <masahiroy@kernel.org>:
> >> On Thu, Jun 10, 2021 at 4:04 PM Helge Deller <deller@gmx.de> wrote:
> >>>
> >>> Hi Masahiro,
> >>>
> >>> On 6/10/21 4:03 AM, Masahiro Yamada wrote:
> >>>> On Thu, Jun 10, 2021 at 7:50 AM Helge Deller <deller@gmx.de> wrote:
>
> [snip]
>
> >>>> But, please keep in mind that there is an issue remaining.
> >>>>
> >>>> Please see this code:
> >>>>
> >>>> ifdef CONFIG_64BIT
> >>>> UTS_MACHINE := parisc64
> >>>> CHECKFLAGS += -D__LP64__=1
> >>>> CC_ARCHES = hppa64
> >>>> LD_BFD := elf64-hppa-linux
> >>>> else # 32-bit
> >>>> CC_ARCHES = hppa hppa2.0 hppa1.1
> >>>> LD_BFD := elf32-hppa-linux
> >>>> endif
> >>>>
> >>>>
> >>>> UTS_MACHINE is determined by CONFIG_64BIT.
> >>>>
> >>>> CONFIG_64BIT is defined only after Kconfig is finished.
> >>>> When you are trying to configure the .config,
> >>>> CONFIG_64BIT is not defined yet.
> >>>> So UTS_MACHINE is always 'parisc'.
> >>>
> >>> Yes.
> >>> See above, but it worked when I had SUBARCH=x86 (when running my laptop).
> >>>
> >>>
> >>>> As you know, Kconfig files now have a bunch of 'cc-option' syntax
> >>>> to check the compiler capability in Kconfig time.
> >>>> Hence, you need to provide a proper compiler in Kconfig time too.
> >>>>
> >>>> When you build a 64-bit parisc kernel on a 32-bit parisc machine,
> >>>
> >>> Please note, that we don't have a 64-bit parisc userspace yet (just kernel).
> >>> This means, that all builds on parisc machines are 32bit and do a
> >>> cross-compilation to a parisc64 kernel if requested in the .config.
> >>>
> >>>> Kconfig is passed with CC=gcc since SUBARCH==UTS_MACHINE==parisc.
> >>>> After Kconfig, CROSS_COMPILE=hppa64-* is set,
> >>>> and the kernel is built by CC=hppa64-*-gcc.
> >>>
> >>> Right. That is the old behaviour. Based on the CONFIG_64BIT option
> >>> the hppa64 compiler is choosen for CROSS_COMPILE.
> >>>
> >>>> So, Kconfig evaluated a compiletely different compiler. This is pointless.
> >>>
> >>> Yes, probably.
> >>>
> >>>
> >>>> There are some options
> >>>>
> >>>> [option 1]
> >>>>    revert the parisc bit of 23243c1ace9fb4eae2f75e0fe0ece8e3219fb4f3
> >>>>    This will restore the functionality you may want, but
> >>>>    as I said above, Kconfig is doing pointless things.
> >>>
> >>> as mentioned above: Doesn't solve the issue.
> >>>
> >>>> [option 2]
> >>>>     Stop using cc-cross-prefix, and pass CROSS_COMPILE explicitly.
> >>>>     This is what many architectures including arm, arm64 do.
> >>>>     You need to explicitly pass CROSS_COMPILE=aarch64-linux-gnu- etc.
> >>>>     if you are cross-compiling arm64.
> >>>
> >>> Might be an option, but it's not as handy as simply choosing CONFIG_64BIT
> >>> and then things are done automatically.
> >>>
> >>>> [option 3]
> >>>>     Introduce ARCH=parisc64.
> >>>>
> >>>>     When you are building 64-bit kernel, you can pass ARCH=parisc64
> >>>>      A patch attached.  (but not tested much)
> >>>
> >>> Tried it, but doesn't work.
> >>> asm-offsets.c is still preprocessed with 32bit compiler (gcc, not hppa20-gcc).
> >>>
> >>> Thanks for your help so far!
> >>> If you like I'm happy to give you an account on a hppa64 machine to reproduce yourself.
> >>> I'll now try to bisect where it goes wrong. There must be something else before commit 23243c1ace9fb4eae2f75e0fe0ece8e3219fb4f3.
> >>>
> >>> Helge
> >>
> >>
> >> Sorry for my late reply.
> >
> > Me too.... :-(
>
> Sorry to jump in even later, but:
>
> I see that
> $ make ARCH=parisc64 defconfig
> does set CONFIG_64BIT.


Strange. It does for me.


masahiro@grover:~/ref/linux-next$ make ARCH=parisc64 defconfig
*** Default configuration is based on 'generic-64bit_defconfig'
#
# configuration written to .config
#
masahiro@grover:~/ref/linux-next$ grep CONFIG_64BIT .config
CONFIG_64BIT=y


> Is there a way to do
> $ make ARCH=parisc64 allmodconfig
> ?
> That does not set CONFIG_64BIT in my testing.
> (testing on linux-next-20220817)


Right.
allmodconfig does not set CONFIG_64BIT.

I think it is the same as before.
Is this thread related?


The reason is 64BIT depends on PA8X00.

allmodconfig chooses PA7000 instead of PA8X00
in the "Processor type" choice since
PA7000 is the default.


If you apply this patch,


diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 7f059cd1196a..458b8e22e240 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -146,7 +146,7 @@ menu "Processor type and features"

 choice
        prompt "Processor type"
-       default PA7000
+       default PA8X00

 config PA7000
        bool "PA7000/PA7100"


allmodconfig will start enabling CONFIG_64BIT,
but it is up to Helge.


> I would like to have a command-line method to do that,
> without editing the .config file.
>
> Thanks.
> --
> ~Randy


-- 
Best Regards
Masahiro Yamada