With pyro the exact same thing is happening!

To make it work this is what I did:

1) in machine conf:

KERNEL_IMAGETYPE = "uImage"
# vmlinux needed for crosstap
KERNEL_ALT_IMAGETYPE = "vmlinux"

I guess I could also add vmlinux to KERNEL_IMAGETYPE = "uImage vmlinux"

2) rebuild kernel

bitbake linux-yocto-custom -c cleansstate && bitbake linux-yocto-custom

3) systemtap-native into sysroot

# with this it works
# After "bitbake systemtap-native" one cannot
# actually run systemtap because it is not installed in a sysroot. 
# "bitbake systemtap-native:do_addto_recipe_sysroot" fixes that.
bitbake -c addto_recipe_sysroot systemtap-native

Maybe this should be documented somewhere if this is an acceptable solution?

Also how can I avoid addto_recipe_sysroot and do this in some bitbake reipe?

Would I need to hack the systemtap recipe or is there a more flexible solutinon?

After more checking with pyro it still does not work:

The crosstap script searches for:

TARGET_KERNEL_BUILDDIR/vmlinux which does not exist:

TARGET_KERNEL_BUILDDIR: /tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/res-custom-pyro-multi-v7-core-image-minimal-sato-sdk-ext/build/build/tmp/work/multi_v7_ml-poky-linux-gnueabi/linux-yocto-custom/4.9.27-custom-ml-debug+gitAUTOINC+89f3b8d5f2-r0/linux-multi_v7_ml-debug-build

ls: cannot access '/tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/res-custom-pyro-multi-v7-core-image-minimal-sato-sdk-ext/build/build/tmp/work/multi_v7_ml-poky-linux-gnueabi/linux-yocto-custom/4.9.27-custom-ml-debug+gitAUTOINC+89f3b8d5f2-r0/linux-multi_v7_ml-debug-build/vmlinux': No such file or directory

I recently tested this with an Genericx86 build and it worked correctly.

The crosstap script is documented about using the add_to_recipe_sysroot, short of having it do that task.

Is the problem that your target kernel is uImage and it's looking for vmlinux and not finding that binary?  Does the uImage binary exist in that directory?

As far as I remember the problem is, that it builds a vmlinux because I tell it to do so:

KERNEL_IMAGETYPE = "uImage vmlinux"

It just expects to find it somewhere else.

It appears the question has been answered.

After having an interactive session with the submitter, I discovered the workflow was including SSTATE which meant that the vmlinux image was not available in the expected WORKDIR area.  I believe the correct solution here is to change the crosstap script to look in the DEPLOY directory and use KERNEL_IMAGETYPE

After reviewing the possible solutions to this, I believe that this is not a bug, but more of a workflow/use case issue.  Since the build was using Shared State and a sstate mirror, the kernel build information was not available. Since even with the kernel pointing the KERNEL_IMAGETYPE it needs additional files.

Since the kernel build dir was not available, the vmlinux binary which is created by most default kernel builds was not there, nor were any of the other build related files that systemtap needs such as the .config file, System.map and others.

systemtap really needs to have a complete local kernel build tree.

The following message is correct:

Error: No target kernel build found.
Did you forget to create a local build of your image?

There was no local build of your kernel.

I assume that having an SSTATE_MIRROR is not a very unusual setup and apparently I did not come across other issues with it so far.

One possible solution (once you figure out that when the kernel is fetched from the SSTATE_MIRROR the kernel sources are not available) is not to populate the SSTATE_MIRROR with the specific kernel you want to use for systemtap.

So at least a hint to this in the documentation would be nice.

Is there a way to invalidate the SSTATE_MIRROR somehow programatically? Something like cleansstate, but also for the mirror?

I think this should work:

1) Use special kernel version for experiments with systemtap
2) Don't populate this kernel in the SSTATE_MIRROR

but this is not very useful, I guess.

This would most likely be more useful:

1) cleansstate kernel
2) disable SSTATE_MIRROR
3) rebuild kernel
4) rebuild image + systemtap

I just discovered the following:

I made a simple BitBake recipe like this:

do_compile() {
        ${CC} simple-hello-world-logging.c ${LDFLAGS} -o simple-logging
         bbdebug 1 "---> Completed do_compile_task <---"
}

If you execute bitbake -c cleansstate simple-logging && bitbake simple-logging

the do_compile task will not be executed in case the build artefacts are found in SSTATE_MIRRORS (same issue as I have here).

... but ...

if I add:

do_compile[nostamp] = "1" 

and run 

bitbake -c cleansstate simple-logging && bitbake simple-logging

the log file is created.

Can't we do something similar here? Just do_xxx[nostamp] = "1" for those tasks which are not run when stuff is found in SSTATE_MIRRORS?

Note to myself:
Status Update / Suggested Resolution for Bug 11403:

The root cause of crosstap / systemtap failing when utilizing an SSTATE_MIRROR or a wiped tmp/ workspace is a missing explicit task dependency in the systemtap recipe metadata loop.

The Problem:
Currently, meta/recipes-kernel/systemtap/systemtap_%.bb defines DEPENDS = "elfutils" but entirely omits a build-time dependency on virtual/kernel. When the build environment pulls the kernel provider (linux-yocto / linux-yocto-dev) out of the Shared State cache, BitBake restores the packaged binaries but skips unpacking or generating the internal kernel source/build artifacts. Because SystemTap requires a fully configured kernel source tree (.config, System.map, generated macros, etc.) to compile its probing backends and instrumentation modules, the task fails immediately due to an empty or missing ${STAGING_KERNEL_BUILDDIR}.

Relying purely on a runtime installation dependency (RDEPENDS += "kernel-devsrc") does not protect host side or cross-compilation tasks from this parse-time isolation defect.

The Fix:
The recipe requires a strict task tracking constraint injected into the BitBake DAG (Directed Acyclic Graph). This forces the build engine to unpack and regenerate the shared kernel artifacts before SystemTap attempts compilation, regardless of whether the kernel was built locally or restored from an SSTATE package.

The following lines should be upstreamed into the core systemtap recipe (or handled via a platform .bbappend):

# Ensure virtual/kernel is present in the build-time dependency map
DEPENDS += "virtual/kernel"

# Force BitBake to populate the shared kernel build folder and headers 
# BEFORE systemtap triggers its configuration and compilation routines
do_configure[depends] += "virtual/kernel:do_shared_workdir"