Since some scripts are executed using "python", create a symlink when "python3" exists
and "python" does not exist, by installing python-is-python3 package.
/bin/sh: 1: python: not found
make[2]: *** [Makefile:364: check_links] Error 127
File types that we don't format automatically can end up
with such basic untidiness as trailing whitespaces.
Check for these. Remove all existing precedents.
Commit 43f1389ddc ("Makefile: enable clang-tidy in presubmit tests")
added clang-tidy to only tools/docker/env/Dockerfile file. We should try to
explicitly install clang-tidy in Makefile for those who don't use docker.
/bin/sh: 1: clang-tidy: not found
(...snipped...)
Makefile:250: recipe for target 'tidy' failed
make[2]: *** [tidy] Error 127
make[2]: *** Waiting for unfinished jobs....
(...snipped...)
Makefile:269: recipe for target 'presubmit_smoke' failed
make[1]: *** [presubmit_smoke] Error 2
Makefile:264: recipe for target 'presubmit' failed
make: *** [presubmit] Error 2
Otherwise the versions in go.mod are updated on running `make
install_prerequisites` leading to inconsistent vendoring errors:
go: inconsistent vendoring in /go/src/github.com/google/syzkaller:
golang.org/x/net@v0.0.0-20200625001655-4c5254603344: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
golang.org/x/tools@v0.0.0-20200717024301-6ddee64345a6: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
golang.org/x/net@v0.0.0-20200520182314-0ba52f642ac2: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
golang.org/x/tools@v0.0.0-20200626171337-aa94e735be7f: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Install g++-riscv64-linux-gnu in install_prerequisites target and hook
up arch_linux_riscv64_target.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
* mmap syscall is special on Linux s390x because
the parameters for this syscall are passed as a struct
on user stack instead of registers.
* Introduce the SyscallTrampolines table into targets.Target
to address the above problem.
* There is a bug in Linux kernel s390x which causes QEMU TCG
to hang when KASAN is enabled. The bug has been fixed
in the forthcoming Linux 5.8 version. Until then do not enable
KASAN when using QEMU TCG, QEMU KVM shall have no problems with
KASAN.
Signed-off-by: Alexander Egorenkov <Alexander.Egorenkov@ibm.com>
Goes through crash folder that is stated in the workdir.
Collects the crashes, counts and tags.
usage:
./bin/syz-reporter -config manager.cfg
Signed-off-by: Jukka Kaartinen <jukka.kaartinen@unikie.com>
1. Use --no-print-directory.
These "Entering directory"/"Leaving directory" messages are completely useless.
2. Use go build instead of go install.
This is just to test build and we don't install anything otherwise.
Don't mess with GOAPTH/bin unnecessarily.
3. Don't export MAKEFLAGS.
It is exported by default.
4. Suppress descriptions up-to-date check output.
It's cryptic and is not particularly useful.
Some terms are normalised on the technical level
but may be oppressive on a societal level.
Replace them with more technically neutral terms.
See the following doc for a longer version:
https://tools.ietf.org/id/draft-knodel-terminology-00.html
On top of syz-env it provides akaros/fuchsia/netbsd toolchains and gcloud sdk.
With this it's possible to run dashboard/app tests on CI and locally
and test executor build and pkg/{csource,cover} for these OSes.
Update #1765
syz-env provides a canned dev environment with all tools necessary
(Go, gcc, clang-format, etc) for development/testing in a form
of a Docker image. Example use:
$ syz-env make presubmit
$ syz-env make extract SOURCEDIR=~/linux
Update #1699
syz-env will be a good, short name for the planned
docker-ized build environment. So rename syz-env to syz-make.
Maybe not the best name, but it's not visible basically anywhere.
Allow targets.go use Clang instead of the default Linux compiler by
setting the SYZ_CLANG=1 env var. Doing so changes the compiler to
"clang" and the linker to "ld.ldd", assuming they are in $PATH, and adds
the --target and -ferror-limit CFLAGS.
Target also exports KernelCompiler and KernelLinker fields now, which allows
overriding the compiler and linker in the kernel make invocation.
Signed-off-by: Alexander Potapenko <glider@google.com>
In preparation to running some tests as github actions.
Both Travis and Github define CI env var, while TRAVIS is, well,
too Travis-specific.
Update #1699
Move this part from .travis.yml to Makefile.
It's useful to see it always and we generally
don't have lots of logic in the travis file.
Also move list of changed files to the bottom
(that's what one generally sees at console
and at the end of the log).
Run fewer builds in presubmit. Also run them sequentially instead of parallel.
The current presubmit OOMs on CI every other time, this is not useful.
Update #1699
Checking in the generated descriptions files makes few things simpler,
but causes pain for pull requests: (1) PRs that touch descriptions
_always_ conflict, (2) PRs are large and harder to review,
(3) people sometimes forget to add auto-generated files.
The proposed way does not require us to hardcode lots of dependencies
in the Makefile (which is nice) and seem to work.
Let's see how it works.
The main contributor-visible consequence is that the auto-generated
files do not need to be checked-in now.
Credit for figuring the Makefile magic goes to @melver.
Fixes#1291
1. Detect when compiler is present, but is not functioning
(can't build a simple program, common for Linux distros).
2. Be more strict with skipping tests due to missing/broken compilers on CI
(on CI they should work, so fail loudly if not).
3. Dedup this logic across syz-env and pkg/csource tests.
4. Add better error reporting for syz-env.
Fixes#1606
We did it for caching purposes, but now
(1) go command caches everything anyway,
(2) we use custom tags and flags, so result
of go install is not reused anyway.
We are seeing some one-off panics during Deserialization
and it's unclear if it's machine memory corrpution or
an actual bug in prog. I leam towards machine memory corruption
but it's impossible to prove without seeing the orig program.
Move git revision to prog and it's more base package
(sys can import prog, prog can't import sys).
Currently we print them as part of `make genereate`,
but nobody reads them, too much output each time.
Don't print them in `make generate` and instead
print in syz-check, the warn files are a good mechanism
to handle "known warnings".
fops_probe utility helps to understand what file_operations callbacks
are attached to a particular file. Requries KCOV and KALLSYMS.
Build with:
g++ tools/fops_probe/fops_probe.cc -Wall -static -o fops_probe
Then copy the binary to target machine and run as:
./fops_probe /dev/fb0
You should see output similar to:
ffffffff81bcccb9 vfs_read
................
ffffffff83af85c3 fb_read
ffffffff83b52af5 cirrusfb_sync
ffffffff81bcd219 vfs_write
................
ffffffff83af7fe2 fb_write
ffffffff83b52af5 cirrusfb_sync
ffffffff81c1b745 do_vfs_ioctl
ffffffff83af7ea9 fb_ioctl
ffffffff81a4ea44 do_mmap
................
ffffffff83af716c fb_mmap
which allows to understand what callbacks are associated with /dev/fb0.
These used to be required to build Fuchsia's Go toolchain to build
syz-fuzzer to run on Fuchsia. However, Fuchsia now uses HostFuzzer
mode, so only syz-executor (written in C) needs to run on Fuchsia; all
Go code runs on the Host OS (currently Linux).