linux.git/arch/parisc/Makefile, branch v6.7

kbuild: unify vdso_install rules

2023-10-28T12:09:02+00:00

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada
Acked-by: Sven Schnelle # s390
Reviewed-by: Nicolas Schier
Reviewed-by: Guo Ren
Acked-by: Helge Deller # parisc
Acked-by: Catalin Marinas
Acked-by: Russell King (Oracle)

arch/parisc: Implement fb_is_primary_device() under arch/parisc

2023-04-20T08:04:58+00:00

Move PARISC's implementation of fb_is_primary_device() into the
architecture directory. This the place of the declaration and
where other architectures implement this function. No functional
changes.

Signed-off-by: Thomas Zimmermann 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Acked-by: Arnd Bergmann 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-14-tzimmermann@suse.de

arch/parisc: Remove trailing whitespaces

2023-04-20T08:04:54+00:00

Fix trailing whitespaces. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Acked-by: Arnd Bergmann 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-13-tzimmermann@suse.de

kbuild: remove head-y syntax

2022-10-02T09:06:03+00:00

Kbuild puts the objects listed in head-y at the head of vmlinux.
Conventionally, we do this for head*.S, which contains the kernel entry
point.

A counter approach is to control the section order by the linker script.
Actually, the code marked as __HEAD goes into the ".head.text" section,
which is placed before the normal ".text" section.

I do not know if both of them are needed. From the build system
perspective, head-y is not mandatory. If you can achieve the proper code
placement by the linker script only, it would be cleaner.

I collected the current head-y objects into head-object-list.txt. It is
a whitelist. My hope is it will be reduced in the long run.

Signed-off-by: Masahiro Yamada 
Tested-by: Nick Desaulniers 
Reviewed-by: Nicolas Schier

parisc: remove arch/parisc/nm

2022-05-29T09:39:35+00:00

Parisc overrides 'nm' with a shell script. I was hit by a false-positive
error of $(NM) because this script returns the exit status of grep
instead of ${CROSS_COMPILE}nm. (grep returns 1 if no lines were selected)

I tried to fix it, but in the code review, Helge suggested to remove it
entirely. [1]

This script was added in 2003. [2]

Presumably, it was a workaround for old toolchains (but even the parisc
maintainer does not know the detail any more).

Hopefully, recent tools should work fine.

[1]: https://lore.kernel.org/all/1c12cd26-d8aa-4498-f4c0-29478b9578fe@gmx.de/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=36eaa6e4c0e0b6950136b956b72fd08155b92ca3

Suggested-by: Helge Deller 
Signed-off-by: Masahiro Yamada 
Acked-by: Helge Deller

kbuild: factor out the common installation code into scripts/install.sh

2022-05-11T12:45:53+00:00

Many architectures have similar install.sh scripts.

The first half is really generic; it verifies that the kernel image
and System.map exist, then executes ~/bin/${INSTALLKERNEL} or
/sbin/${INSTALLKERNEL} if available.

The second half is kind of arch-specific; it copies the kernel image
and System.map to the destination, but the code is slightly different.

Factor out the generic part into scripts/install.sh.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nicolas Schier

parisc: Detect hppa-suse-linux-gcc compiler for cross-building

2022-03-29T19:37:12+00:00

Allow the system to find the SUSE hppa compiler and linker to set
CROSS32_COMPILE and CROSS_COMPILE.

Suggested-by: Jiri Slaby 
Signed-off-by: Helge Deller

parisc: Always use the self-extracting kernel feature

2022-03-11T18:49:30+00:00

This patch drops the CONFIG_PARISC_SELF_EXTRACT option.

The palo boot loader is able to decompress a kernel which was compressed
with gzip. That possibility was useful when the Linux kernel
self-extracting feature wasn't implemented yet.

Beside the fact that the self-extracting feature offers much better
compression rates, we do support self-extracting kernels already since
kernel v4.14, so now it's really time to get rid of that old option and
always use the self-extractor.

Signed-off-by: Helge Deller

parisc: Add vDSO support

2022-03-11T18:49:30+00:00

Add minimal vDSO support, which provides the signal trampoline helpers,
but none of the userspace syscall helpers like time wrappers.

The big benefit of this vDSO implementation is, that we now don't need
an executeable stack any longer. PA-RISC is one of the last
architectures where an executeable stack was needed in oder to implement
the signal trampolines by putting assembly instructions on the stack
which then gets executed. Instead the kernel will provide the relevant
code in the vDSO page and only put the pointers to the signal
information on the stack.

By dropping the need for executable stacks we avoid running into issues
with applications which want non executable stacks for security reasons.
Additionally, alternative stacks on memory areas without exec
permissions are supported too.

This code is based on an initial implementation by Randolph Chung from 2006:
https://lore.kernel.org/linux-parisc/4544A34A.6080700@tausq.org/

I did the porting and lifted the code to current code base. Dave fixed
the unwind code so that gdb and glibc are able to backtrace through the
code. An additional patch to gdb will be pushed upstream by Dave.

Signed-off-by: Helge Deller 
Signed-off-by: Dave Anglin 
Cc: Randolph Chung 
Signed-off-by: Helge Deller

parisc: Fix KBUILD_IMAGE for self-extracting kernel

2021-11-30T20:49:32+00:00

Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting
(CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built.
This fixes the bindeb-pkg make target.

Signed-off-by: Helge Deller 
Cc:  # v4.14+