Add installation targets for bash and zsh autocompletions for the PV
related tools. Do not use them by default.
Acked-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This introduces libzpci which is a library intended to handle s390x
specific PCI attributes and peculiarities. As a first step it introduces
code to list PCI devices on s390x including an initial set of s390x
specific attributes like FID, PFT, UID etc. It also collects information
on network device associated with a particular PCI function. The
included example serves as a demonstration of using libzpci to list PCI
devices.
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes the following error:
$ make CROSS_COMPILE=s390x-linux-gnu- HOST_ARCH=s390x
../../../common.mak:117: *** Please specify CROSS_COMPILE=... and try it again!. Stop.
$ make --version
GNU Make 4.4.1
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390-tools doesn't define a common C/C++ standard at the moment.
Set the standard to gnu11/gnu++11, which is also used by the Kernel, and
establish a common baseline for all tools.
The -std flag is added to ALL_CFLAGS and ALL_CXXFLAGS to avoid losing it
in case CFLAGS are set by an outside entity.
It is also added to CLAGS_FOR_BUILD for this one special cross build
case.
The -std flag is removed from all tools that set it manually until now.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes the following error (using GNU Make 4.3.0):
make[2]: command: Command not found
The reason for this is that `command` is a bash builtin. `command` is
used in `common.mak` for the `combdb` Makefile target.
While at it, remove the now useless `SHELL := /bin/bash` definitions in
the sub-Makefiles.
Fixes: 3d098416c6 ("common.mak: add `compdb` Makefile target")
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The rust integration into the s390-tools build system consists of the
following steps:
- Add a subdirectory for the rust code.
- Add a Makefile that forwards rust builds to `cargo`.
- Add a `utils` crate for rust code in s390-tools.
- Add rust stuff for dotfiles:
- gitignore
- editorconfig
- codespellrc (while at it, add an ignore file)
With cargo the rust ecosystem has its own build system which also is
responsible to resolve rust dependencies via downloading the dependencies
from (default) crates.io and discover the source files. Therefore, the
Makefile just calls `cargo build` to forward the build to cargo.
If a rust crate does not require external dependencies, users might call
rustc directly.
A simple `make` will build all the rust targets as well (with --release
specified). Also `make install` will work as usual.
A few Makefile configuration variables are introduced for rust/Cargo:
- HAVE_CARGO (default 1) to toggle the build of rust code using cargo
- CARGOFLAGS to add custom cargo flags, e.g. --offline
- CARGO Cargo binary location defaults to
$(where cargo)
A new global make target is defined to get the current s390-tools
version:
$ make version
2.28.0
rust/Makefile also has the `print-rust-targets` target to print all rust
directories/crates that should be shipped/installed.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Acked-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Commit 62ec87680a61 ("common.mak: improve cross compilation support")
added one extra whitespace during the changes of the toolchain command
definitions. The rest of the commands did not receive that change.
Since then the pretty print output looks like this:
...
CC zipl/boot/eckd1b.o
CXX ziomon/ziorep_collapser.o
SED zdev/src/lszdev_usage.c
CC hyptop/sd_cpu_items.o
MV zfcpdump/zfcpdump-initrd
LINK dasdfmt/dasdfmt
...
Add the additional whitespace to all other tools definitions used during
the build process.
Note: This doesn't fix the misaligned indentation for commands like
$(CC_FOR_BUILD) as those inherit the whitespace from the original
command, here $(CC).
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use a minimal assembly snippet to check for linker flags. This has the
advantage that it will work even if only the cross-toolchain is
installed, but not, for example, stdlib.
Using the C snippet, the check runs in a similar error like this:
/usr/bin/s390x-linux-gnu-ld: cannot find crt1.o: No such file or directory
/usr/bin/s390x-linux-gnu-ld: cannot find crti.o: No such file or directory
/usr/bin/s390x-linux-gnu-ld: cannot find -lc: No such file or directory
/usr/bin/s390x-linux-gnu-ld: cannot find crtn.o: No such file or directory
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'clean' build targets can be specified alongside other targets,
which causes an immediate removal of build artifacts. Make 'clean'
targets mutually exclusive to avoid this issue and display an error if
'clean' is used in combination with other targets.
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Introduce `BUILD_ARCH` and `(CC|LINK|...|OBJDUMP)_FOR_BUILD` variables
in order to properly support the build of tools that generate code or
data during the build process. Replace existing variables `HOSTCC` with
`CC_FOR_BUILD` and `HOSTCFLAGS` `CFLAGS_FOR_BUILD`. The Makefile
variables for the `HOST_ARCH` are unchanged.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
In addition, add the ability that a Makefile that includes `common.mak`
can specify the `HOST_ARCH`. Usage example:
$S390_TOOLS/mytool/Makefile:
``` Makefile
HOST_ARCH := s390x
include ../common.mak
```
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The relative subdirectory path of a build target is determined via a
separate shell command that issues 'cd' and 'pwd'. Spawning a separate
shell is very costly and can lead to extremely slow builds in some
circumstances.
Replace the shell command with the make built-in command 'realpath' to
accomplish the same result more efficiently.
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
For a slightly easier development loop add a pseudo compilation of the
zfcpdbf Perl script. This will run the Perl interpreter in syntax-check
mode:
-c causes Perl to check the syntax of the program and then exit
without executing it. Actually, it will execute any "BEGIN",
"UNITCHECK", or "CHECK" blocks and any "use" statements: these are
considered as occurring outside the execution of your program.
"INIT" and "END" blocks, however, will be skipped.
Additionally add the `-w` switch when the Make variable `W` is `1`. This
will print additional warnings about dubious constructs (according to
Perl).
So this pseudo compilation only happens whenever the script is changed
during development create a file `.zfcpdbf.ct` as a result so we can
describe the relationship and dependency in Make. This file can be ignored
otherwise.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently, each generated loader binary is linked into one data.o object
file which is then linked against boot.o. The data.o file is also used
to generate the data.h header file using nm, which will contain all
symbols required by zipl.
The linking process is somewhat depended on the directory, as the symbol
names are derived from the file names of the input files, which is the
default behavior of the linker. The file name in this case being the
entire path.
Examples for the current situation (starting from root dir in each case):
$ cd zipl/boot && make eckd0_cdl.bin
$ cc -no-pie -static -nostdlib -Wl,--relocatable -Wl,--format,binary -o data.o eckd0_cdl.bin
$ nm data.o
0000000000000018 D _binary_eckd0_cdl_bin_end
0000000000000018 A _binary_eckd0_cdl_bin_size
0000000000000000 D _binary_eckd0_cdl_bin_start
$ make -C zipl/boot eckd0_cdl.bin
$ cc -no-pie -static -nostdlib -Wl,--relocatable -Wl,--format,binary -o data.o zipl/boot/eckd0_cdl.bin
$ nm data.o
000000000000018 D _binary_zipl_boot_eckd0_cdl_bin_end
000000000000018 A _binary_zipl_boot_eckd0_cdl_bin_size
000000000000000 D _binary_zipl_boot_eckd0_cdl_bin_start
The example above shows that the entire path would end up in the symbol
name if specified that way.
To make this more robust, future proof, and get more control of the
resulting symbol names, use '.incbin' and some macros for embedding the
loader binary files. This also reduces the linker step and the
generation of the data.h header file.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Co-developed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This disables the following warning `ld: warning: stage3.exec has a LOAD
segment with RWX permissions` for newer linker. This changes nothing in
functionality for the zipl bootloaders, since only the binaries and not
the ELF files are actually used.
Acked-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The library libvmdump is written in C++ and uses exception handling
and class inheritance. The tools vmur and vmconnect are compiled using
the C++ compiler for linking with the libvmdump library.
With integration of vmdump file support into the zgetdump tool and
the removal of vmur vmdump file conversion support there is no need
anymore the vmconvert tool.
With removal of the tool vmconvert, the libvmdump library written in C++
has no more user and can be deleted.
Remove the vmconvert command from the zgetdump man page.
Remove the directories libvmdump and vmconvert and adjust the Makefile.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Suggested-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Commit ae7217806b ("common.mak: remove `LINK` and `LINKXX`") changed
the LINK and LINKXX definition to ensure that the same compiler is used
for compilation and linking when specified with CC= (or CXX=
respectively) on the commandline.
However, the commit also removed the pretty print for both commands. Add
the pretty print back in and use the already defined $(CC) and $(CXX)
variables to preserve the original change.
Fixes: ae7217806b ("common.mak: remove `LINK` and `LINKXX`")
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
`afl-clang` requires a white space between a option name and the option value.
Therefore let's fix this for `-xc` by adding a white space.
How to reproduce:
$ make -C zdump CC=afl-clang-fast LINK=afl-clang-fast
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The dracut installation directory is referenced from `chreipl-fcp-mpath`,
`zdev`, and `zipl`; in each with its own individual definition and
variable name. This makes it unnecessarily hard to change it when
installing from the top level directory of s390-tools and passing
variable overwrites via the command line.
Fix this by defining a common `DRACUTDIR` variable in the shared
`common.mak` file, and referencing this in each tool as base directory.
With this a user can simply pass `DRACUTDIR=/foo/bar/baz` on the
commandline and change the installation for all three tools.
Further, also derive common `DRACUTCONFDIR` and `DRACUTMODDIR` variables
from `DRACUTDIR` in `common.mak`, so that `zdev` and `zipl` don't use
different variable names for the same directory anymore, and all these
are defined together in a common place.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
UDEVDIR is used in both `chreipl-fcp-mpath` and `zdev`, but with a
different meaning. In the former it points to the base udev directory,
not the rules directory; in the later it points to the rules directory.
If someone was to call `make` from the top level directory, and set
UDEVDIR for the whole build/installation, it would either break `zdev`
or `chreipl-fcp-mpath` (depending on what it was set to).
Fix this by pulling the definition of it in the shared `common.mak`
file, and giving it a common meaning. Point UDEVDIR to the base udev
directory, and UDEVRULESDIR to the rules directory below it.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Remove `-rdynamic` since it's a linker flag. This should not cause any problems
because we differentiate between compilation and linking by default. While at
it, adapt the `print_backtrace` documentation accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
