| Summary: | crosstap doesn't work on qemuppc and qemumips | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Yi Zhao <yi.zhao> |
| Component: | kernel | Assignee: | Tom Zanussi <tom.zanussi> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bruce.ashfield, jessica.zhang, ke.zou, poky.bs.watcher, poky.watcher, tom.zanussi, yi.zhao |
| Version: | 1.5 | ||
| Target Milestone: | 1.5.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
From recipes-kernel/systemtap/systemtap_git.inc: # systemtap doesn't support mips For qemuppc, there is a legitimate problem. With the 3.8 kernel, we added -grecord-gcc-switches to the Makefile if -mfentry was being used, which temporarily fixed the problem and was a requirement for the systemtap workaround for the problem to work. See here for details: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4099 The root cause however was bad debuginfo generation by gcc; this problems was fixed in gcc 4.8 which is what we use in dora. In 3.10 we don't add the Makefile switch because the gcc fix is there and does fix the problem for all the other arches, so the Makefile switch is no longer needed. For some reason the problem still exists for ppc despite the gcc-4.8 fix. I've verified that turning off CONFIG_FUNCTION_TRACER makes the problem go away, and that things work properly even with CONFIG_FUNCTION_TRACER for qemux86-64 and qemux86 where the problem was originally seen. I've also verified that the problem no longer exists if systemtap 1.4 is used, so something in 1.4 fixed the problem although a scan through the git history doesn't show anything obvious. I'll have to dig further to find the commit that fixes it - simply upgrading to 1.4 as has already been done in master would fix the problem, but we can't do that for a point release. In 1.5.1 rc2, the crosstap still can't work in qemuppc. Patch submitted to oe-core. Pulled into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=db7caba32cc00591f1ae4378332dea1b372db20a This is in master, but also in dora-next, which is actually what this bug is referencing, but that's 1.5.2, so change the version. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=robert/dora-next i.e. this bug is complete, but can't be closed until it hits dora. I'm closing this as it's been fixed for awhile and it doesn't make sense to keep it on the rolls until when it someday gets merged. Verification can be against dora-next. |
Git rev: master/78b91ab23d9856525fc7ac1bb8da2975382813bf Steps: 1.Create the trace_open.stp script as follows: probe syscall.open { printf ("%s(%d) open (%s)\n", execname(), pid(), argstr) } 2.Bitbake a qemuppc or qemumips core-image-sato-sdk image and start it under qemu. 3.From the host machine poky build_dir, run "crosstap root@192.168.7.2 trace_open.stp". For qemuppc, I got the following errors: ####################### semantic error: not accessible at this address [man error::dwarf] (0xc0135218, dieoffset: 0xb2fca3): identifier '$filename' at /buildarea/poky/build-qemuppc/tmp/sysroots/x86_64-linux/usr/share/systemtap/tapset/linux/syscalls2.stp:128:32 source: filename = user_string_quoted($filename) ^ semantic error: not accessible at this address [man error::dwarf] (0xc0135218, dieoffset: 0xb2fcb3): identifier '$flags' at :129:10 source: flags = $flags ^ semantic error: not accessible at this address [man error::dwarf] (0xc0135218, dieoffset: 0xb2fca3): identifier '$filename' at :132:54 source: argstr = sprintf("%s, %s, %#o", user_string_quoted($filename), ^ Pass 2: analysis failed. [man error::pass2] ######################### For qemumips, I got the following errors: ######################### Error: Native (host) systemtap not found. Did you accidentally build a local non-sdk image? (or forget to add 'tools-profile' to EXTRA_IMAGE_FEATURES in your local.conf)? ######################### There is no stap command in $SYSTEMTAP_HOST_INSTALLDIR/usr/bin/.