Bug 4403

Summary: stap fails on core-image-sato x86-64
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Alexandru Georgescu <alexandru.c.georgescu>
Component: meta-yoctoAssignee: Tom Zanussi <tom.zanussi>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: Low CC: bogdan.a.marinescu, ioanax.grigoropol, poky.bs.watcher, poky.watcher, richard.purdie, sgw
Version: 1.4   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Alexandru Georgescu 2013-04-23 12:42:59 UTC
poky 789b2b7e0cca404ff8ba8ed5ba823d215e6ba5b4
HOST: Fedora 18 64bit


STEPS TO REPRODUCE:
1. Build a core-image-sato qemux86-64 with stap support (add tools-profile to EXTRA_IMAGE_FEATURES)

2. Launch the qemu image

3. I have the following error in qemux86-64 core-image-sato when using stap:

root@qemux86-64:~# stap trace.stp 
Checking "/lib/modules/3.8.4-yocto-standard/build/.config" failed with error: No such file or directory
root@qemux86-64:~# 



Trace file: 
root@qemux86-64:~# cat trace.stp 
probe syscall.open
{
        printf ("%s(%d) open (%s)\n", execname(), pid(), argstr)
}

probe timer.ms(4000) # after 4 seconds
{
        exit ()
}
root@qemux86-64:~# 


5. When using crosstap from the host, I have the following:

[yocto@localhost build]$ crosstap root@192.168.7.4 trace.stp 
/mnt/ssd/0418-1/poky/build /mnt/ssd/0418-1/poky/build
/mnt/ssd/0418-1/poky/build
root@192.168.7.4's password: 
[yocto@localhost build]$
Comment 1 Tom Zanussi 2013-04-23 22:05:30 UTC
OK, the first thing is that invoking a script in the target isn't a supported use-case - only from the host.  Invoking a .stp script directly on the target requires the ability to compile a kernel module on the target, and hasn't been tested under those conditions.

The only supported mechanism is via 'crosstap', and I don't see any indication in the output that it failed - just no output, which is very possible if no files were opened on the target.  Try opening some files on the host and see if there's still no output.
Comment 2 Ioana Grigoropol 2013-04-24 13:19:34 UTC
Hi Tom,

The error message Alex received is reproducible by running the crosstap script on a qemu machine that has a different architecture than specified in conf/local.conf.
I have two macines: arm and x86_64, and conf/local.conf MACHINE points to qemuarm.

When running crosstap script for the arm machine, the output is:
~/git-repos/poky/build [master] $ crosstap root@192.168.7.2 ../test.stp
~/git-repos/poky/build ~/git-repos/poky/build
~/git-repos/poky/build
syslogd(391) open ("/var/log/messages", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE|O_NOCTTY|O_NONBLOCK, 0666)

If I run the script for qemux86-64(without changing the config), the output is:
~/git-repos/poky/build [master] $ crosstap root@192.168.7.4 ../test.stp
~/git-repos/poky/build ~/git-repos/poky/build
~/git-repos/poky/build
Checking "/lib/modules/3.8.4-yocto-standard/build/.config" failed with error: No such file or directory

After changing to qemux84-64, everything works fine:

~/git-repos/poky/build [master] $ vim conf/local.conf 
~/git-repos/poky/build [master] $ crosstap root@192.168.7.4 ../test.stp
~/git-repos/poky/build ~/git-repos/poky/build
~/git-repos/poky/build
dmesg(628) open ("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC)
dmesg(628) open ("/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC)
dmesg(628) open ("/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC)
dmesg(628) open ("/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC)
dmesg(628) open ("/lib/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC)
~/git-repos/poky/build [master] $ 

Couldn't the architecture be determined using the ip from the script instead of the local.conf ? Something like "ssh root@IP uname -m" ?

Thanks,
Ioana
Comment 3 Tom Zanussi 2013-04-24 13:43:21 UTC
Yeah, the problem in this case is that crosstap uses bitbake to get a number of variables that it uses in the script:

BITBAKE_VARS=`bitbake -e virtual/kernel`

So having MACHINE pointing to something different will cause it to used the wrong values.

At minimum, this should be documented, and probably the script can detect this and print out a message to that effect.

We could also provide a way to override the settings it gets from the wrong machine, as you suggest.

I'm not sure at this point about the best way to fix it robustly, but in any case it's easily worked around, and in fact not a common thing that people run into - hadn't seen it until now.
Comment 4 Richard Purdie 2017-06-13 11:15:51 UTC
This appears to be user error in setting an incorrect MACHINE. In an ideal world we'd check the MACHINE setting matched the target but I'm not sure how we'd do that. This doesn't stand much chance of being implemented as we're not actively working on crosstap so resolving as user error when testing.