Git rev: dylan/7ab82abcad9ede847c42c01d2a4f4c2c18877e6f This issue was fixed on 1.4 with bug 4099, but now it happens on 1.4.3. Please refer to bug 5403 and 4099. 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 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". Error message: ###################### semantic error: not accessible at this address [man error::dwarf] (0xc012cdc0, dieoffset: 0xc1840d): identifier '$flags' at /buildarea3/yzhao1/poky-build/build-cross/tmp/sysroots/x86_64-linux/usr/share/systemtap/tapset/linux/syscalls2.stp:129:10 source: flags = $flags ^ semantic error: not accessible at this address [man error::dwarf] (0xc012cdc0, dieoffset: 0xc183fd): identifier '$filename' at :132:54 source: argstr = sprintf("%s, %s, %#o", user_string_quoted($filename), ^ Pass 2: analysis failed. [man error::pass2] ####################
I'm not sure what to do with this; the fix is definitely in the kernel source branch we're using for qemuppc. Tom, any suggestions?
At this point, I would suggest bisecting to figure out what caused the regression - if I'm not mistaken, the number of commits between broken and not should be pretty small.
Well, FWIW I just tried this on a fresh build of 1.4.2 and it failed there, so this isn't a 1.4.3 regression. (CentOS 6.5 build machine.)
(In reply to comment #3) > Well, FWIW I just tried this on a fresh build of 1.4.2 and it failed there, > so this isn't a 1.4.3 regression. (CentOS 6.5 build machine.) I tested it on original 1.4 , it also failed.
Could we re-test this on master just to make sure it definitely works there?
*** Bug 6016 has been marked as a duplicate of this bug. ***
IIRC, this was a result of the way later gcc compiles the kernel causing some issues in the debuginfo that scrambles the function entries and variable locations. We have had this kind of failures before at Enea, in particular with the scheduler.stp file. We wrote some patches around the issue for scheduler.stp but those do not solve the root cause. Some related bugs are already reported/fixed upstream, not sure if they help with our problem : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 https://sourceware.org/bugzilla/show_bug.cgi?id=15123 I would say we need to investigate if the existing fixes solve our problem and, if not, push the problem upstream.
(In reply to comment #7) > IIRC, this was a result of the way later gcc compiles the kernel causing > some issues in the debuginfo that scrambles the function entries and > variable locations. > > We have had this kind of failures before at Enea, in particular with the > scheduler.stp file. We wrote some patches around the issue for scheduler.stp > but those do not solve the root cause. > > Some related bugs are already reported/fixed upstream, not sure if they help > with our problem : > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 > https://sourceware.org/bugzilla/show_bug.cgi?id=15123 > > I would say we need to investigate if the existing fixes solve our problem > and, if not, push the problem upstream. If you look at the yocto bugs mentioned e.g. 4099 and 5403, you can see that the fix was incorporating those upstream gcc and systemtap fixes. The fixes did work and were verified by QA at that point - apparently the whole situation is so fragile that unrelated patches added to the point release broke it again. You mentioned that you have patches that fix the issue - if could please submit them, that would help. For master, I'll try upgrading systemtap to the very latest commit and see if it fixes the problem. If it does, great, if not, we may just have to remove systemtap support for ppc unless someone comes up with fixes. For 1.4.3, we may or may not be able to upgrade to the latest systemtap, if not, we'll probably have to remove support for ppc unless someone can come up with fixes. It's not a great use of our time to be chasing down bugs in fundamentally broken software.
This will not make 1.4.3 at this point, and is not likely to get fixed for 1.4 in general. Will un-duplicate Bug 6016 opened against master. If someone wants to perform the work to fix this for 1.4, please reopen and assign the bug to yourself.