* print_ubacktrace() and ppc 32 @ 2013-06-17 14:24 Holger Brunck 2013-06-17 17:43 ` Mark Wielaard 2013-06-17 17:46 ` David Smith 0 siblings, 2 replies; 13+ messages in thread From: Holger Brunck @ 2013-06-17 14:24 UTC (permalink / raw) To: systemtap Hi all, I am using systemtap userspace probes on a 32-Bit powerpc architecture. I do crosscompile the probes on a 64-Bit x86 host. The version I use is: Systemtap translator/driver (version 2.3/0.152, non-git sources) If I use print_ubacktrace() in my stap script it won't compile. I am getting two main error messages and I ask myself which one tells me the real reason for the error: backtraces for 32bit programs on 64bit kernels don't work. systemtap-2.3-32645/share/systemtap/runtime/stack.c:85:2: error: #error "Unsupported architecture" So is userspace backtrace not supported at all for PPC? Or does the problem come due to a misconfiguration in my setup because I crosscompile on a 64 Bit host architecture for a 32 Bit target architecture? Regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 14:24 print_ubacktrace() and ppc 32 Holger Brunck @ 2013-06-17 17:43 ` Mark Wielaard 2013-06-17 18:00 ` Lukas Berk 2013-06-18 6:46 ` Holger Brunck 2013-06-17 17:46 ` David Smith 1 sibling, 2 replies; 13+ messages in thread From: Mark Wielaard @ 2013-06-17 17:43 UTC (permalink / raw) To: Holger Brunck; +Cc: systemtap On Mon, 2013-06-17 at 16:24 +0200, Holger Brunck wrote: > I am using systemtap userspace probes on a 32-Bit powerpc architecture. I do > crosscompile the probes on a 64-Bit x86 host. > > The version I use is: > Systemtap translator/driver (version 2.3/0.152, non-git sources) > > If I use print_ubacktrace() in my stap script it won't compile. I am getting two > main error messages and I ask myself which one tells me the real reason for the > error: > > backtraces for 32bit programs on 64bit kernels don't work. Yes, if your powerpc kernel is 64bit, but the user program is 32bit (same for 32bit user space on x86_64) then you will get that warning during stap translation time (the stap script should still run, but won't produce a user backtrace for the 32bit module/library/process). This is bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10272 "backtraces fail with 32-on-64 executables" > systemtap-2.3-32645/share/systemtap/runtime/stack.c:85:2: error: #error > "Unsupported architecture" This might be caused by the cross compiling, maybe something got confused about the architecture. You get that when: #ifndef STP_USE_DWARF_UNWINDER powerpc (and x86_64) both should use the DWARF_UNWINDER. So you might want to look at why that doesn't get defined in your case. Cheers, Mark ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 17:43 ` Mark Wielaard @ 2013-06-17 18:00 ` Lukas Berk 2013-06-17 18:05 ` Mark Wielaard 2013-06-18 6:46 ` Holger Brunck 1 sibling, 1 reply; 13+ messages in thread From: Lukas Berk @ 2013-06-17 18:00 UTC (permalink / raw) To: Mark Wielaard; +Cc: Holger Brunck, systemtap [-- Attachment #1: Type: text/plain, Size: 1767 bytes --] Hey, > On Mon, 2013-06-17 at 16:24 +0200, Holger Brunck wrote: > > I am using systemtap userspace probes on a 32-Bit powerpc architecture. I do > > crosscompile the probes on a 64-Bit x86 host. > > > > The version I use is: > > Systemtap translator/driver (version 2.3/0.152, non-git sources) > > > > If I use print_ubacktrace() in my stap script it won't compile. I am getting two > > main error messages and I ask myself which one tells me the real reason for the > > error: > > > > backtraces for 32bit programs on 64bit kernels don't work. > > Yes, if your powerpc kernel is 64bit, but the user program is 32bit > (same for 32bit user space on x86_64) then you will get that warning > during stap translation time (the stap script should still run, but > won't produce a user backtrace for the 32bit module/library/process). > This is bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10272 > "backtraces fail with 32-on-64 executables" > > > systemtap-2.3-32645/share/systemtap/runtime/stack.c:85:2: error: #error > > "Unsupported architecture" > > This might be caused by the cross compiling, maybe something got > confused about the architecture. You get that when: > #ifndef STP_USE_DWARF_UNWINDER > powerpc (and x86_64) both should use the DWARF_UNWINDER. So you might > want to look at why that doesn't get defined in your case. Unfortunately I believe this is because we don't actually support powerpc32 (only ppc64.h is defined in unwind.h). So while the first error you're getting is being worked on (I'm currently working on PR10272[1] so hopefully it'll be resloved soon), the second error will be the show stopper here. Thanks, Lukas [1] - http://sourceware.org/bugzilla/show_bug.cgi?id=10272 [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 18:00 ` Lukas Berk @ 2013-06-17 18:05 ` Mark Wielaard 2013-06-18 7:01 ` Holger Brunck 0 siblings, 1 reply; 13+ messages in thread From: Mark Wielaard @ 2013-06-17 18:05 UTC (permalink / raw) To: Lukas Berk; +Cc: Holger Brunck, systemtap On Mon, 2013-06-17 at 14:00 -0400, Lukas Berk wrote: > > On Mon, 2013-06-17 at 16:24 +0200, Holger Brunck wrote: > > > systemtap-2.3-32645/share/systemtap/runtime/stack.c:85:2: error: #error > > > "Unsupported architecture" > > > > This might be caused by the cross compiling, maybe something got > > confused about the architecture. You get that when: > > #ifndef STP_USE_DWARF_UNWINDER > > powerpc (and x86_64) both should use the DWARF_UNWINDER. So you might > > want to look at why that doesn't get defined in your case. > > Unfortunately I believe this is because we don't actually support > powerpc32 (only ppc64.h is defined in unwind.h). So while the first > error you're getting is being worked on (I'm currently working on > PR10272[1] so hopefully it'll be resloved soon), the second error will > be the show stopper here. Yeah thanks. I had completely forgotten I only implemented the DWARF unwinder for ppc64. Sorry. This was because when I wrote the powerpc DWARF unwinder (kernel support) I only had access to ppc64 kernels. So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h definitions file. It should not be that hard to write based on the ppc64.h version and the ppc32 DWARF register mappings from http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf But note that testing might be needed to see if those really map to actually used DWARF register numbers generated by the toolchain. As can be seen in the comments in ppc64.h sometimes mistakes have been made and theory/spec and practice are not the same :{ Cheers, Mark ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 18:05 ` Mark Wielaard @ 2013-06-18 7:01 ` Holger Brunck 2013-08-03 1:12 ` Lukas Berk 0 siblings, 1 reply; 13+ messages in thread From: Holger Brunck @ 2013-06-18 7:01 UTC (permalink / raw) To: Mark Wielaard; +Cc: Lukas Berk, systemtap Hi, On 06/17/2013 08:05 PM, Mark Wielaard wrote: >> Unfortunately I believe this is because we don't actually support >> > powerpc32 (only ppc64.h is defined in unwind.h). So while the first >> > error you're getting is being worked on (I'm currently working on >> > PR10272[1] so hopefully it'll be resloved soon), the second error will >> > be the show stopper here. > Yeah thanks. I had completely forgotten I only implemented the DWARF > unwinder for ppc64. Sorry. This was because when I wrote the powerpc > DWARF unwinder (kernel support) I only had access to ppc64 kernels. > ah ok thanks so it's currently unsupported. > So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h > definitions file. It should not be that hard to write based on the > ppc64.h version and the ppc32 DWARF register mappings from > http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf > But note that testing might be needed to see if those really map to > actually used DWARF register numbers generated by the toolchain. As can > be seen in the comments in ppc64.h sometimes mistakes have been made and > theory/spec and practice are not the same :{ Ok thanks for pointing out. If someone has a first ppc32.h file and needs some help for testing on a native 32 bit ppc system, let me know. Or maybe in the next week I find the time to implement one. Best regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-18 7:01 ` Holger Brunck @ 2013-08-03 1:12 ` Lukas Berk 2013-08-05 8:46 ` Holger Brunck 0 siblings, 1 reply; 13+ messages in thread From: Lukas Berk @ 2013-08-03 1:12 UTC (permalink / raw) To: Holger Brunck; +Cc: Mark Wielaard, systemtap [-- Attachment #1.1: Type: text/plain, Size: 934 bytes --] Hey, > > So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h > > definitions file. It should not be that hard to write based on the > > ppc64.h version and the ppc32 DWARF register mappings from > > http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf > > But note that testing might be needed to see if those really map to > > actually used DWARF register numbers generated by the toolchain. As can > > be seen in the comments in ppc64.h sometimes mistakes have been made and > > theory/spec and practice are not the same :{ > > Ok thanks for pointing out. If someone has a first ppc32.h file and needs > some help for testing on a native 32 bit ppc system, let me know. Or maybe > in the next week I find the time to implement one. Looking over the DWARF register specs the mappings should be the same, so hopefully we can use the same header file. Would you mind trying this patch? Cheers, Lukas [-- Attachment #1.2: ppc32.patch --] [-- Type: text/plain, Size: 417 bytes --] diff --git a/runtime/unwind/unwind.h b/runtime/unwind/unwind.h index 056b539..7a4fab8 100644 --- a/runtime/unwind/unwind.h +++ b/runtime/unwind/unwind.h @@ -23,7 +23,7 @@ struct unwind_frame_info #include "x86_64.h" #elif defined (__i386__) #include "i386.h" -#elif defined (__powerpc64__) +#elif defined (__powerpc64__) || defined (__powerpc__) #include "ppc64.h" #elif defined (__s390x__) #include "s390x.h" [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-08-03 1:12 ` Lukas Berk @ 2013-08-05 8:46 ` Holger Brunck 2013-08-06 19:07 ` Lukas Berk 0 siblings, 1 reply; 13+ messages in thread From: Holger Brunck @ 2013-08-05 8:46 UTC (permalink / raw) To: Lukas Berk; +Cc: Mark Wielaard, systemtap Hi, On 08/03/2013 03:12 AM, Lukas Berk wrote: >>> So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h >>> definitions file. It should not be that hard to write based on the >>> ppc64.h version and the ppc32 DWARF register mappings from >>> http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf >>> But note that testing might be needed to see if those really map to >>> actually used DWARF register numbers generated by the toolchain. As can >>> be seen in the comments in ppc64.h sometimes mistakes have been made and >>> theory/spec and practice are not the same :{ >> >> Ok thanks for pointing out. If someone has a first ppc32.h file and needs >> some help for testing on a native 32 bit ppc system, let me know. Or maybe >> in the next week I find the time to implement one. > > Looking over the DWARF register specs the mappings should be the same, > so hopefully we can use the same header file. Would you mind trying > this patch? > no unfortunately it does not work. First I had to fix a compile error because "softe" is not defined for ppc_32 in the linux kernel in ptrace.h. I changed it temporary to "mq" in runtime/unwind/ppc_64.h and then I was able to compile my probe. I gave it a try with a simple main.c which calls a function foo(). My probe was: probe process("/usr/local/bin/main").function("foo") { print_ubacktrace() } But the output is: 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] So the calling function main() was not shown on an ARM architecture a similar setup shows: 0x83b8 : foo+0x14/0x64 [/usr/local/bin/main] 0x8444 : main+0x3c/0x40 [/usr/local/bin/main] So there is still something missing for ppc32. Best regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-08-05 8:46 ` Holger Brunck @ 2013-08-06 19:07 ` Lukas Berk 2013-08-07 7:16 ` Holger Brunck 0 siblings, 1 reply; 13+ messages in thread From: Lukas Berk @ 2013-08-06 19:07 UTC (permalink / raw) To: Holger Brunck; +Cc: Mark Wielaard, systemtap [-- Attachment #1: Type: text/plain, Size: 1042 bytes --] Hey, [...] > no unfortunately it does not work. First I had to fix a compile error because > "softe" is not defined for ppc_32 in the linux kernel in ptrace.h. I changed it > temporary to "mq" in runtime/unwind/ppc_64.h and then I was able to compile my > probe. > > I gave it a try with a simple main.c which calls a function foo(). My probe was: > > probe process("/usr/local/bin/main").function("foo") > { > print_ubacktrace() > } > Ok > But the output is: > 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] > > So the calling function main() was not shown on an ARM architecture a similar > setup shows: > 0x83b8 : foo+0x14/0x64 [/usr/local/bin/main] > 0x8444 : main+0x3c/0x40 [/usr/local/bin/main] > > So there is still something missing for ppc32. Ah too bad it wasn't a simple plug and play :) Would you mind trying again but running your script with the added stap option '-DDEBUG_UNWIND=99' and supplying the output? (ie, stap -DDEBUG_UNWIND=99 --ldd -ve 'probe... ) Thanks, Lukas [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-08-06 19:07 ` Lukas Berk @ 2013-08-07 7:16 ` Holger Brunck 2013-08-09 15:21 ` Lukas Berk 0 siblings, 1 reply; 13+ messages in thread From: Holger Brunck @ 2013-08-07 7:16 UTC (permalink / raw) To: Lukas Berk; +Cc: Mark Wielaard, systemtap On 08/06/2013 09:07 PM, Lukas Berk wrote: >> >> So there is still something missing for ppc32. > > Ah too bad it wasn't a simple plug and play :) Would you mind trying > again but running your script with the added stap option > '-DDEBUG_UNWIND=99' and supplying the output? (ie, stap -DDEBUG_UNWIND=99 > --ldd -ve 'probe... ) > probe compiled with: stap -DDEBUG_UNWIND=99 -g -a powerpc -B CROSS_COMPILE=powerpc-linux- script.stp On the target the trace output of staprun is: _stp_stack_unwind_one_user:460: STARTING user unwind 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] _stp_stack_unwind_one_user:476: CONTINUING user unwind to depth 1 unwind:1452: pc=10000448, 10000448 unwind:1492: trying debug_frame unwind_frame:1168: Module /usr/local/bin/main: no unwind frame data unwind:1496: debug_frame failed: -5, trying eh_frame unwind_frame:1168: Module /usr/local/bin/main: no unwind frame data unwind:1504: unwinding failed: -5 _stp_stack_unwind_one_user:500: ret=-5 PC=10000448 SP=bfffd640 And the probed binary is crashing: stap_ac60c2e404cade1c833497ae4f16b820_1577: systemtap: 2.3/0.152, base: cc581000, memory: 34data/68text/3ctx/2058net/8alloc kb, probes: 1 Unable to handle kernel paging request for data at address 0xbffffb10 Faulting instruction address: 0xc04965d4 Oops: Kernel access of bad area, sig: 11 [#2] PREEMPT km82xx Modules linked in: stap_ac60c2e404cade1c833497ae4f16b820_1577(O) [last unloaded: stap_ac60c2e404cade1c833497ae4f16b820_1577] CPU: 0 PID: 407 Comm: main Tainted: G D O 3.10.0-04826-gc82c8d0-dirty #7 task: c7bab160 ti: c7b8c000 task.ti: c7b8c000 NIP: c04965d4 LR: c0000028 CTR: c03c742c REGS: c7b8de10 TRAP: 0300 Tainted: G D O (3.10.0-04826-gc82c8d0-dirty) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44000284 XER: 20000000 DAR: bffffb10, DSISR: 20000000 GPR00: c00bd950 c7b8dec0 c7bab160 c69d2104 c7b8df50 00000002 cc902209 38205350 GPR08: c0000000 c050b668 00000000 3b9aca00 28000288 10018794 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 100ab3f5 10081f20 c0440928 00000000 GPR24: c69d20d0 c69d2104 c69d20c0 00000000 c7b8c000 c7b8df50 c0000028 00000002 NIP [c04965d4] prom_init+0x28/0xfc0 LR [c0000028] __start+0x1c/0x30 Call Trace: [c7b8dec0] [c00bd950] uprobe_notify_resume+0x4dc/0x920 (unreliable) [c7b8df30] [c00099b0] do_notify_resume+0x78/0x94 [c7b8df40] [c0010848] do_user_signal+0x74/0xc4 --- Exception: 700 at 0x10000448 LR = 0x100004ec Instruction dump: 9361004c 7cbb2b78 93a10054 7c9d2378 93c10058 7fc802a6 93e1005c 7cbf2b78 90010064 91c10018 93810050 91810014 <821efae8> 823eff98 88040000 829efaec ---[ end trace e21ded4f2ec79037 ]--- Segmentation fault Version numbers: Kernel: v3.10 gcc: powerpc-gcc (GCC) 4.6.4 20120303 (prerelease) systemtap: 2.3-32645 Best regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-08-07 7:16 ` Holger Brunck @ 2013-08-09 15:21 ` Lukas Berk 2013-08-12 8:58 ` Holger Brunck 0 siblings, 1 reply; 13+ messages in thread From: Lukas Berk @ 2013-08-09 15:21 UTC (permalink / raw) To: Holger Brunck; +Cc: Mark Wielaard, systemtap [-- Attachment #1: Type: text/plain, Size: 3021 bytes --] Hey, I quickly discussed this with Mark, comments inline. [...] > > probe compiled with: > stap -DDEBUG_UNWIND=99 -g -a powerpc -B CROSS_COMPILE=powerpc-linux- script.stp > Looks good. > On the target the trace output of staprun is: > > _stp_stack_unwind_one_user:460: STARTING user unwind > 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] > _stp_stack_unwind_one_user:476: CONTINUING user unwind to depth 1 > unwind:1452: pc=10000448, 10000448 > unwind:1492: trying debug_frame > unwind_frame:1168: Module /usr/local/bin/main: no unwind frame data > unwind:1496: debug_frame failed: -5, trying eh_frame > unwind_frame:1168: Module /usr/local/bin/main: no unwind frame data > unwind:1504: unwinding failed: -5 > _stp_stack_unwind_one_user:500: ret=-5 PC=10000448 SP=bfffd640 I'm going to assume debuginfo is present, but if stap can't find the debug_frame or eh_frame, the unwinder shouldn't continue. > > And the probed binary is crashing: > > stap_ac60c2e404cade1c833497ae4f16b820_1577: systemtap: 2.3/0.152, base: > cc581000, memory: 34data/68text/3ctx/2058net/8alloc kb, probes: 1 > Unable to handle kernel paging request for data at address 0xbffffb10 > Faulting instruction address: 0xc04965d4 > Oops: Kernel access of bad area, sig: 11 [#2] > PREEMPT km82xx > Modules linked in: stap_ac60c2e404cade1c833497ae4f16b820_1577(O) [last unloaded: > stap_ac60c2e404cade1c833497ae4f16b820_1577] > CPU: 0 PID: 407 Comm: main Tainted: G D O 3.10.0-04826-gc82c8d0-dirty #7 > task: c7bab160 ti: c7b8c000 task.ti: c7b8c000 > NIP: c04965d4 LR: c0000028 CTR: c03c742c > REGS: c7b8de10 TRAP: 0300 Tainted: G D O (3.10.0-04826-gc82c8d0-dirty) > MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44000284 XER: 20000000 > DAR: bffffb10, DSISR: 20000000 > > GPR00: c00bd950 c7b8dec0 c7bab160 c69d2104 c7b8df50 00000002 cc902209 38205350 > GPR08: c0000000 c050b668 00000000 3b9aca00 28000288 10018794 00000000 00000000 > GPR16: 00000000 00000000 00000000 00000000 100ab3f5 10081f20 c0440928 00000000 > GPR24: c69d20d0 c69d2104 c69d20c0 00000000 c7b8c000 c7b8df50 c0000028 00000002 > NIP [c04965d4] prom_init+0x28/0xfc0 > LR [c0000028] __start+0x1c/0x30 > Call Trace: > [c7b8dec0] [c00bd950] uprobe_notify_resume+0x4dc/0x920 (unreliable) > [c7b8df30] [c00099b0] do_notify_resume+0x78/0x94 > [c7b8df40] [c0010848] do_user_signal+0x74/0xc4 > --- Exception: 700 at 0x10000448 > LR = 0x100004ec > Instruction dump: > 9361004c 7cbb2b78 93a10054 7c9d2378 93c10058 7fc802a6 93e1005c 7cbf2b78 > 90010064 91c10018 93810050 91810014 <821efae8> 823eff98 88040000 829efaec > ---[ end trace e21ded4f2ec79037 ]--- > > Segmentation fault > > Version numbers: > Kernel: v3.10 > gcc: powerpc-gcc (GCC) 4.6.4 20120303 (prerelease) > systemtap: 2.3-32645 Ouch, would you mind running a simple hello world style probe? Along the lines of 'probe process.function("main") {log("Hello")}' and seeing if that runs properly? Thanks for testing, Lukas [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-08-09 15:21 ` Lukas Berk @ 2013-08-12 8:58 ` Holger Brunck 0 siblings, 0 replies; 13+ messages in thread From: Holger Brunck @ 2013-08-12 8:58 UTC (permalink / raw) To: Lukas Berk; +Cc: Mark Wielaard, systemtap Hi, [..] On 08/09/2013 05:20 PM, Lukas Berk wrote: > > Ouch, would you mind running a simple hello world style probe? Along the > lines of 'probe process.function("main") {log("Hello")}' and seeing if > that runs properly? > sorry there was something wrong in my last setup and I was unable to reproduce this crash. Therefore I decided to rebuild a setup which is 100% reproducible. My previous test was made with our internal kernel branch which has some changes to the mainline kernel. So I took kernel 3.10.0. Compared to the original kernel I only added the needed config options to mgcoge_defconfig for uprobe support (relay, kprobes, module support...). I recompiled the systemtap host binaries with the latest snapshot: systemtap-20130810.tar.bz2 I did three changes compared to the original code to get the test for the powerpc backtrace support compilable: diff --git a/share/systemtap/runtime/linux/runtime.h b/share/systemtap/runtime/linux/runtime.h --- a/share/systemtap/runtime/linux/runtime.h +++ b/share/systemtap/runtime/linux/runtime.h @@ -134,7 +134,7 @@ static struct Only define STP_USE_DWARF_UNWINDER when STP_NEED_UNWIND_DATA, as set through a pragma:unwind in one of the [u]context-unwind.stp functions. */ -#if (defined(__arm__) || defined(__i386__) || defined(__x86_64__) || defined(__powerpc64__)) || defined (__s390x__) +#if (defined(__arm__) || defined(__i386__) || defined(__x86_64__) || defined(__powerpc64__)) || defined (__s390x__) || (__powerpc__) #ifdef STP_NEED_UNWIND_DATA #ifndef STP_USE_DWARF_UNWINDER #define STP_USE_DWARF_UNWINDER diff --git a/share/systemtap/runtime/unwind/ppc64.h b/share/systemtap/runtime/unwind/ppc64.h --- a/share/systemtap/runtime/unwind/ppc64.h +++ b/share/systemtap/runtime/unwind/ppc64.h @@ -54,7 +54,7 @@ PTREGS_INFO(gpr[29]), \ PTREGS_INFO(gpr[30]), \ PTREGS_INFO(gpr[31]), \ - PTREGS_INFO(softe), \ + PTREGS_INFO(mq), \ PTREGS_INFO(ctr), \ PTREGS_INFO(link), \ PTREGS_INFO(nip) diff --git a/share/systemtap/runtime/unwind/unwind.h b/share/systemtap/runtime/unwind/unwind.h --- a/share/systemtap/runtime/unwind/unwind.h +++ b/share/systemtap/runtime/unwind/unwind.h @@ -25,6 +25,8 @@ struct unwind_frame_info #include "i386.h" #elif defined (__powerpc64__) #include "ppc64.h" +#elif defined (__powerpc__) +#include "ppc64.h" #elif defined (__s390x__) #include "s390x.h" #elif defined (__arm__) A simple hello_world works fine. Then I compiled my stapprobe with ubacktrace: systemtap-2.4-32473/bin/stap -DDEBUG_UNWIND=99 -g -a powerpc -B CROSS_COMPILE=powerpc- script.stp and let it run on the target. The output is: WARNING: unwind Bad num=67108864 end-ptr=32 2*tableSize=8 _stp_stack_unwind_one_user:460: STARTING user unwind 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] _stp_stack_unwind_one_user:476: CONTINUING user unwind to depth 1 unwind:1612: pc=10000448, 10000448 unwind:1652: trying debug_frame set_no_state_rule:398: reg=23, where=1 _stp_search_unwind_hdr:915: binary search for 10000448 unwind_frame:1331: /usr/local/bin/main: fde=0 unwind_frame:1399: cie=0 fde=0 startLoc=0 endLoc=0, pc=10000448 unwind:1656: debug_frame failed: -5, trying eh_frame set_no_state_rule:398: reg=23, where=1 _stp_search_unwind_hdr:915: binary search for 10000448 adjustStartLoc:866: adjustStartLoc=100002e0, ptrType=DW_EH_PE_datarel_sdata4, m=/usr/local/bin/main, s=.absolute eh=1 adjustStartLoc:874: eh_frame=ca54fd50, eh_frame_addr=10000668 adjustStartLoc:866: adjustStartLoc=100002e0, ptrType=DW_EH_PE_datarel_sdata4, m=/usr/local/bin/main, s=.absolute eh=1 adjustStartLoc:874: eh_frame=ca54fd50, eh_frame_addr=10000668 _stp_search_unwind_hdr:980: fde off=1000067c _stp_search_unwind_hdr:990: returning fde=ca54fd64 startLoc=100002e0 unwind_frame:1331: /usr/local/bin/main: fde=ca54fd64 unwind_frame:1336: /usr/local/bin/main: cie=ca54fd50 parse_fde_cie:291: codeAlign=4, dataAlign=fffffffc parse_fde_cie:305: map retAddrReg value 65 to reg_info idx 34 parse_fde_cie:369: startLoc: ca54f9c8, locrange: 24 adjustStartLoc:866: adjustStartLoc=ca54f9c8, ptrType=DW_EH_PE_pcrel_sdata4, m=/usr/local/bin/main, s=.absolute eh=1 adjustStartLoc:874: eh_frame=ca54fd50, eh_frame_addr=10000668 unwind_frame:1351: startLoc: 100002e0, endLoc: 10000304 unwind_frame:1353: pc (10000448) > endLoc(10000304) unwind:1664: unwinding failed: 1 Best regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 17:43 ` Mark Wielaard 2013-06-17 18:00 ` Lukas Berk @ 2013-06-18 6:46 ` Holger Brunck 1 sibling, 0 replies; 13+ messages in thread From: Holger Brunck @ 2013-06-18 6:46 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap Hi Mark, On 06/17/2013 07:43 PM, Mark Wielaard wrote: >> If I use print_ubacktrace() in my stap script it won't compile. I am getting two >> > main error messages and I ask myself which one tells me the real reason for the >> > error: >> > >> > backtraces for 32bit programs on 64bit kernels don't work. > Yes, if your powerpc kernel is 64bit, but the user program is 32bit > (same for 32bit user space on x86_64) then you will get that warning > during stap translation time (the stap script should still run, but > won't produce a user backtrace for the 32bit module/library/process). > This is bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10272 > "backtraces fail with 32-on-64 executables" > no it's not a 32 Bit program running on a 64bit machine it's a 32 bit ppc binary crosscompiled on a 64 bit x86 architecture. The target architecture is a 32 bit ppc. Best regards Holger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: print_ubacktrace() and ppc 32 2013-06-17 14:24 print_ubacktrace() and ppc 32 Holger Brunck 2013-06-17 17:43 ` Mark Wielaard @ 2013-06-17 17:46 ` David Smith 1 sibling, 0 replies; 13+ messages in thread From: David Smith @ 2013-06-17 17:46 UTC (permalink / raw) To: Holger Brunck; +Cc: systemtap, Mark Wielaard On 06/17/2013 09:24 AM, Holger Brunck wrote: > Hi all, > I am using systemtap userspace probes on a 32-Bit powerpc architecture. I do > crosscompile the probes on a 64-Bit x86 host. > > The version I use is: > Systemtap translator/driver (version 2.3/0.152, non-git sources) > > If I use print_ubacktrace() in my stap script it won't compile. I am getting two > main error messages and I ask myself which one tells me the real reason for the > error: > > backtraces for 32bit programs on 64bit kernels don't work. > systemtap-2.3-32645/share/systemtap/runtime/stack.c:85:2: error: #error > "Unsupported architecture" > > So is userspace backtrace not supported at all for PPC? Or does the problem come > due to a misconfiguration in my setup because I crosscompile on a 64 Bit host > architecture for a 32 Bit target architecture? It looks like ppc64 is supported, at least according to runtime/linux/runtime.h. If 'powerpc64' is defined, STP_USE_DWARF_UNWINDER gets defined. Does getting a backtrace for a simple 64-bit program work? I've CC'ed Mark Wielaard, who might know off the top of his head what the status of getting a 32-bit backtrace on ppc64 is. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-08-12 8:58 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-17 14:24 print_ubacktrace() and ppc 32 Holger Brunck 2013-06-17 17:43 ` Mark Wielaard 2013-06-17 18:00 ` Lukas Berk 2013-06-17 18:05 ` Mark Wielaard 2013-06-18 7:01 ` Holger Brunck 2013-08-03 1:12 ` Lukas Berk 2013-08-05 8:46 ` Holger Brunck 2013-08-06 19:07 ` Lukas Berk 2013-08-07 7:16 ` Holger Brunck 2013-08-09 15:21 ` Lukas Berk 2013-08-12 8:58 ` Holger Brunck 2013-06-18 6:46 ` Holger Brunck 2013-06-17 17:46 ` David Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).