3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-27 04:01:36 +01:00
Code Issues Releases Wiki Activity

userland: native testing

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2019-05-05 00:00:00 +00:00
parent 5daad53289
commit 8509f17a84
37 changed files with 142 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
README.adoc
View File

@@ -984,16 +984,20 @@ cd userland
Source: link:userland/c/hello.c[].
Build an entire directory:
Build an entire directory and test it:
....
cd userland
./build c
./test c
....
Build the current directory:
Build the current directory and test it:
....
cd userland/c
./build
./test
....
Note however that if you run this from link:userland/[] toplevel, it would try to build the link:userland/libs/[] folder, which depends on certain libraries being installed on the host, e.g. <<blas>>.
@@ -1005,21 +1009,10 @@ cd linux-kernel-module-cheat
./build --download-dependencies userland-host
....
The `build` scripts inside link:userland/[] are just symlinks to link:build-userland-in-tree[] which you can also use from toplevel as:
Pass custom compiler options:
....
./build-userland-in-tree
./build-userland-in-tree c
./build-userland-in-tree c/hello.c
./build-userland-in-tree userland/c/hello.c
....
which is in turn just a thin wrapper around link:build-userland[], so you can use any option supported by that script freely.
Pass custom compiler options with:
....
./build-userland --ccflags='-foptimize-sibling-calls -foptimize-strlen' --force-rebuild
./build --ccflags='-foptimize-sibling-calls -foptimize-strlen' --force-rebuild
....
Here we used `--force-rebuild` to force rebuild since the sources weren't modified since the last build.
@@ -1027,19 +1020,48 @@ Here we used `--force-rebuild` to force rebuild since the sources weren't modifi
Some CLI options have more specialized flags, e.g. `-O` optimization level:
....
./build-userland --optimization-level 3 --force-rebuild
./build --optimization-level 3 --force-rebuild
....
See also <<user-mode-static-executables>> for `--static`.
Do a more clean out-of-tree build and run the program instead:
The `build` scripts inside link:userland/[] are just symlinks to link:build-userland-in-tree[] which you can also use from toplevel as:
....
./build-userland-in-tree
./build-userland-in-tree userland/c
./build-userland-in-tree userland/c/hello.c
....
`build-userland-in-tre` is in turn just a thin wrapper around link:build-userland[]:
....
./build-userland --gcc-which host --in-tree userland/c
....
So you can use any option supported by `build-userland` script freely with `build-userland-in-tree` and `build`.
The situation is analogous for link:userland/test[], link:test-user-mode-in-tree[] and link:test-user-mode[].
Do a more clean out-of-tree build instead and run the program:
....
./build-userland --gcc-which host --userland-build-id host
"$(./getvar --userland-build-id host userland_build_dir)/hello.out"
./run --emulator native --userland userland/c/hello.c --userland-build-id host
....
Here we put the host executables in a separate <<build-variants,build-variant>> to avoid conflict with Buildroot builds.
Here we:
* put the host executables in a separate <<build-variants,build-variant>> to avoid conflict with Buildroot builds.
* ran with the `--emulator native` option to run the program natively
In this case you can debub the program with:
....
./run --debug-vm --emulator native --userland userland/c/hello.c --userland-build-id host
....
as shown at: <<debug-the-emulator>>, although direct GDB host usage works as well of course.
===== Userland setup getting started full system