print_ubacktrace() and ppc 32

print_ubacktrace() and ppc 32

[Holger Brunck]

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

Re: print_ubacktrace() and ppc 32

[Mark Wielaard]

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

Re: print_ubacktrace() and ppc 32

[Lukas Berk]

[-- 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 --]

Re: print_ubacktrace() and ppc 32

[Mark Wielaard]

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

Re: print_ubacktrace() and ppc 32

[Holger Brunck]

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   

Re: print_ubacktrace() and ppc 32

[Lukas Berk]

[-- 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 --]

Re: print_ubacktrace() and ppc 32

[Holger Brunck]

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

Re: print_ubacktrace() and ppc 32

[Lukas Berk]

[-- 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 --]

Re: print_ubacktrace() and ppc 32

[Holger Brunck]

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

Re: print_ubacktrace() and ppc 32

[Lukas Berk]

[-- 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 --]

Re: print_ubacktrace() and ppc 32

[Holger Brunck]

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

Re: print_ubacktrace() and ppc 32

[Holger Brunck]

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

Re: print_ubacktrace() and ppc 32

[David Smith]

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)