[Copying the systemtap community about an issue seen with uprobes based
testcases.....]

On Mon, Jan 17, 2011 at 04:32:36PM +0100, Mark Wielaard wrote:
> On Mon, 2011-01-17 at 20:24 +0530, K.Prasad wrote:
> > Upon running a "make RUNTESTFLAGS='exelib.exp' check", the following
> > testcases fail:
> > 
> > Running /home/prasadkr/systemtap/testsuite/systemtap.exelib/exelib.exp
> > ...
> > FAIL: uprobeslibgcc-O3default-prelink-debug prelink ./libuprobeslibgcc-O3default-prelink-debug.so
> > FAIL: uprobeslibgcc-O3default-prelink-sep-debug prelink ./libuprobeslibgcc-O3default-prelink-sep-debug.so
> > FAIL: uprobeslibgcc-O3default-prelink-sep-debug-after prelink ./libuprobeslibgcc-O3default-prelink-sep-debug-after.so
> 
> These indicate that the prelink step failed. Could you look in the
> systemtap.log file to see why?
> 

The prelink package was missing before and upon installation, it
appears that the "make RUNTESTFLAGS='exelib.exp' installcheck" is
failing because of unmatched symbol names....(a snippet of 
systemtap.log pasted below)

print_ustack exe 1^M
 0x00000000100006a0 : 00000011.plt_call.__libc_start_main@@GLIBC_2.3+0+0x188/0x3b0 [/usr/share/systemtap/testsuite/uprobesgcc-O3default-debug-uprobeslibgcc-O3default-debug_exe]^M

I also happen to find that the backtrace doesn't contain any symbol
beyond the top of the stack, which probably indicates that the frame
pointer information for full stack unwinding is missing in which case
implementation of dwarf unwinding may be required. Kindly let us know
if this is the case.

On the other hand, probing a simple helloworld.c program also results in
similar output

#include <stdio.h>

__attribute__((noinline))
void print_hw()
{
	printf("Hello world\n");
}

int main()
{
	print_hw();
	return 0;
}

# stap -k -e 'probe process("/home/prasadkr/helloworld").function("print_hw") { printf("0x%x : %s\n", uaddr(), usymdata(uaddr())) }' -c ./helloworld
Hello world
0x10000530 : 00000011.plt_call.__libc_start_main@@GLIBC_2.3+0+0x188/0x350 [/home/prasadkr/helloworld]
Keeping temporary directory "/tmp/stapQw4jDx"

However, it looks like the corresponding stap-symbols.h appears fine
(with the function names intact), so it is not clear where the problem
lies (whether the issue is insufficient unwind information or incorrect
symbol names or both). I've attached the same for your reference.

> 
> This looks like the address is off. We would expect something that
> contains "print_hw" in the name. Could you try if the basic probe
> address and symbol resolution works? What does the following give?
> 
> $ stap -k -e 'probe process("./helloworld").function("print_hw")
>                { printf("0x%x : %s\n", uaddr(), usymdata(uaddr())) }' \
>        -c ./helloworld
> 
> That should also give you the symbols/addresses that the translator
> stores in something like /tmp/stapR7QjNW/stap-symbols.h
> Please take a look if those look somewhat sane (the addresses will have
> to be adjusted to runtime load addresses later).
> 
> > I'm also attaching the systemtap.log .sum after collected from the
> > execution of exelib.exp testcase.
> 
> You forgot to attach those.
>

I'm attaching the systemtap.log output obtained after running a "make
RUNTESTFLAGS='exelib.exp' installcheck" now.

Thanks,
K.Prasad