Hi Masahiro,
On 6/10/21 4:03 AM, Masahiro Yamada wrote:
On Thu, Jun 10, 2021 at 7:50 AM Helge Deller <deller@xxxxxx> wrote:
On 6/1/21 12:21 PM, Meelis Roos wrote:
Upstream Linux git fails to compile on gentoo hppa - .config below.
I have 2 gcc-s as always:
$ gcc-config -l
[1] hppa2.0-unknown-linux-gnu-9.3.0
[2] hppa2.0-unknown-linux-gnu-10.2.0 *
[3] hppa64-unknown-linux-gnu-10.2.0 *
I see the same issue too, but only when compiling natively on a parisc machine.
Cross-compiling on a x86 box works nicely.
First I thought it's a problem with setting the "cross_compiling" flag in ./Makefile.
But that's not sufficient.
On a x86 machine (which builds fine) I get
SRCARCH=parisc SUBARCH=x86 UTS_MACHINE=parisc
The arch/parisc/kernel/asm-offsets.c file gets preprocessed via:
hppa64-linux-gnu-gcc
On a native 32bit parisc machine I have:
SRCARCH=parisc SUBARCH=parisc UTS_MACHINE=parisc
Here the arch/parisc/kernel/asm-offsets.c file gets preprocessed via:
gcc
Instead here the native hppa64-linux-gnu-gcc (cross compiler) should have been used too, since
we build a 64-bit hppa kernel (CONFIG_64BIT is set).
Note, on hppa we don't have an "-m64" compiler flag as on x86.
I see.
hppa is not a bi-arch compiler, in other words,
http- and hppa64- are separate compilers.
Yes.
Mashahiro, do you maybe have an idea what gets wrong here, or which
patch has changed the behaviour how the asm-offsets.c file gets preprocessed?
Presumably, commit 23243c1ace9fb4eae2f75e0fe0ece8e3219fb4f3
Prior to that commit, arch/parisc/Makefile was like this:
ifneq ($(SUBARCH),$(UTS_MACHINE))
ifeq ($(CROSS_COMPILE),)
...
Now I understand why arch/parisc/Makefile was written this way.
Reverting the change in arch/parisc/Makefile will restore the original behavior.
Sadly, reverting this change (23243c1ace9fb4eae2f75e0fe0ece8e3219fb4f3) does not
restore the original behavior.
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
