Results of systemtap-20080517 snapshot on ppc64

Results of systemtap-20080517 snapshot on ppc64

[Srinivasa DS]

Attaching results of systemtap-20080517 snapshot on ppc64. I have 
applied one interim fix(present in bug#6429) and executed the tests.

Test Run By root on Mon May 19 15:43:30 2008
Native configuration is powerpc64-redhat-linux-gnu

                 === systemtap tests ===
Host: Linux llm27lp1.in.ibm.com 2.6.26-rc3 #1 SMP Mon May 19 11:00:06 
IST 2008 ppc64 ppc64ppc64 GNU/Linux
Snapshot: 277f2b79b02bf69a1d72d05b06086b07bcc6a113

FAIL: debugpath-bad (eof)
FAIL: PROCFS shutdown (eof)
FAIL: stmtvars
FAIL: backtrace of yyy_func2 (1)
FAIL: print_stack of yyy_func2 (1)
FAIL: backtrace of yyy_func3 (1)
FAIL: print_stack of yyy_func3 (1)
FAIL: backtrace of yyy_func4 (1)
FAIL: print_stack of yyy_func4 (1)
FAIL: systemtap.examples/sig_by_pid.meta
FAIL: systemtap.examples/sig_by_proc.meta
FAIL: systemtap.examples/sigmon.meta
FAIL: systemtap.maps/ix_hist.stp
FAIL: buildok/nfs-all-probes.stp
FAIL: buildok/process_test.stp
FAIL: buildok/rpc-all-probes.stp
FAIL: buildok/signal-all-probes.stp
FAIL: buildok/task-embedded.stp
FAIL: buildok/task_test.stp
FAIL: semok/nodwf01.stp
FAIL: semok/nodwf02.stp
FAIL: semok/nodwf03.stp
FAIL: systemtap.printf/bin6.stp
FAIL: shared buffer guest
FAIL: buffer sharing (0, 0)
FAIL: 64-bit acct
FAIL: 64-bit readwrite
FAIL: 64-bit signal
FAIL: 32-bit acct
FAIL: 32-bit readwrite
FAIL: 32-bit rt_signal
FAIL: 32-bit signal


                 === systemtap Summary ===

# of expected passes            482
# of unexpected failures        32
# of expected failures          194
# of unknown successes          1
# of known failures             3
# of untested testcases         30
# of unsupported tests          2
runtest completed at Mon May 19 16:51:30 2008

Re: Results of systemtap-20080517 snapshot on ppc64

[Ananth N Mavinakayanahalli]

On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
> Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
> one interim fix(present in bug#6429) and executed the tests.

Looks like there are a higher number of errors compared to the earlier
tests... probably new features?

> Test Run By root on Mon May 19 15:43:30 2008
> Native configuration is powerpc64-redhat-linux-gnu
>
>                 === systemtap tests ===
> Host: Linux llm27lp1.in.ibm.com 2.6.26-rc3 #1 SMP Mon May 19 11:00:06 IST 
> 2008 ppc64 ppc64ppc64 GNU/Linux
> Snapshot: 277f2b79b02bf69a1d72d05b06086b07bcc6a113
>
> FAIL: debugpath-bad (eof)
> FAIL: PROCFS shutdown (eof)
> FAIL: stmtvars
> FAIL: backtrace of yyy_func2 (1)
> FAIL: print_stack of yyy_func2 (1)
> FAIL: backtrace of yyy_func3 (1)
> FAIL: print_stack of yyy_func3 (1)
> FAIL: backtrace of yyy_func4 (1)
> FAIL: print_stack of yyy_func4 (1)
> FAIL: systemtap.examples/sig_by_pid.meta
> FAIL: systemtap.examples/sig_by_proc.meta
> FAIL: systemtap.examples/sigmon.meta
> FAIL: systemtap.maps/ix_hist.stp
> FAIL: buildok/nfs-all-probes.stp
> FAIL: buildok/process_test.stp
> FAIL: buildok/rpc-all-probes.stp
> FAIL: buildok/signal-all-probes.stp
> FAIL: buildok/task-embedded.stp
> FAIL: buildok/task_test.stp
^^^^^^^^^^^
Are these utrace related? Your kernel probably was !UTRACE enabled

> FAIL: semok/nodwf01.stp
> FAIL: semok/nodwf02.stp
> FAIL: semok/nodwf03.stp
^^^^^^^^^^
These are probably related to dwarfless

> FAIL: systemtap.printf/bin6.stp
> FAIL: shared buffer guest
> FAIL: buffer sharing (0, 0)
^^^^^^^^^^
These are Relay buffer related hopefully.

Ananth

Re: Results of systemtap-20080517 snapshot on ppc64

[Srinivasa DS]

Ananth N Mavinakayanahalli wrote:
> On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:

>> FAIL: print_stack of yyy_func4 (1)
>> FAIL: systemtap.examples/sig_by_pid.meta
>> FAIL: systemtap.examples/sig_by_proc.meta
>> FAIL: systemtap.examples/sigmon.meta
>> FAIL: systemtap.maps/ix_hist.stp
>> FAIL: buildok/nfs-all-probes.stp
>> FAIL: buildok/process_test.stp
>> FAIL: buildok/rpc-all-probes.stp
>> FAIL: buildok/signal-all-probes.stp
>> FAIL: buildok/task-embedded.stp
>> FAIL: buildok/task_test.stp
> ^^^^^^^^^^^
> Are these utrace related? Your kernel probably was !UTRACE enabled

No, these scripts print members of task_struct. May be some kernel 
change in 2.6.26-rc tree has caused this bug.

> 
>> FAIL: semok/nodwf01.stp
>> FAIL: semok/nodwf02.stp
>> FAIL: semok/nodwf03.stp
> ^^^^^^^^^^
> These are probably related to dwarfless

Yes, testcases have failed probe systemcalls. Will investigate further..
> 
>> FAIL: systemtap.printf/bin6.stp
>> FAIL: shared buffer guest

Re: Results of systemtap-20080517 snapshot on ppc64

[David Smith]

Ananth N Mavinakayanahalli wrote:
> On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
>> Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
>> one interim fix(present in bug#6429) and executed the tests.
> 
> Looks like there are a higher number of errors compared to the earlier
> tests... probably new features?

It does look like the number of errors went up from 24 (from March 5,
2008) to 32 in this report.

>> FAIL: buildok/task-embedded.stp
>> FAIL: buildok/task_test.stp
> ^^^^^^^^^^^
> Are these utrace related? Your kernel probably was !UTRACE enabled

Nope, those aren't utrace related (those 2 tests check the
tapset/task.stp tapset).  The new utrace probe tests are in
systemtap.base/utrace_p4.exp and systemtap.base/utrace_p5.exp.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Results of systemtap-20080517 snapshot on ppc64

[Jim Keniston]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Mon, 2008-05-19 at 18:19 +0530, Ananth N Mavinakayanahalli wrote:
> On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
> > Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
> > one interim fix(present in bug#6429) and executed the tests.
> 
> Looks like there are a higher number of errors compared to the earlier
> tests... probably new features?
> 
...
> 
> > FAIL: semok/nodwf01.stp
> > FAIL: semok/nodwf02.stp
> > FAIL: semok/nodwf03.stp
> ^^^^^^^^^^
> These are probably related to dwarfless
...

Yup.  Please try the attached patch and see if it fixes the dwarfless
failures.

Ananth et al, can you think of any kernel functions (nm type T or t)
where this simple mapping of ".func" to "func" would cause problems?

> 
> Ananth

Thanks.
Jim

[-- Attachment #2: powerpc_symtab.patch --]
[-- Type: text/x-patch, Size: 431 bytes --]

--- a/tapsets.cxx	2008-05-19 12:02:37.000000000 -0700
+++ b/tapsets.cxx	2008-05-19 12:02:51.000000000 -0700
@@ -4681,6 +4681,11 @@
 symbol_table::add_symbol(const char *name, Dwarf_Addr addr,
                                      Dwarf_Addr *high_addr)
 {
+#ifdef __powerpc__
+  // Map ".sys_foo" to "sys_foo".
+  if (name[0] == '.')
+    name++;
+#endif
   func_info *fi = new func_info();
   fi->addr = addr;
   fi->name = name;

Re: Results of systemtap-20080517 snapshot on ppc64

[Wenji Huang]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Srinivasa DS wrote:
> Attaching results of systemtap-20080517 snapshot on ppc64. I have 
> applied one interim fix(present in bug#6429) and executed the tests.
> 
> Test Run By root on Mon May 19 15:43:30 2008
> Native configuration is powerpc64-redhat-linux-gnu
> 
>                 === systemtap tests ===
> Host: Linux llm27lp1.in.ibm.com 2.6.26-rc3 #1 SMP Mon May 19 11:00:06 
> IST 2008 ppc64 ppc64ppc64 GNU/Linux
> Snapshot: 277f2b79b02bf69a1d72d05b06086b07bcc6a113
> 
> FAIL: debugpath-bad (eof)
> FAIL: PROCFS shutdown (eof)
> FAIL: stmtvars
[...]

I found stmtvars failed due to regexp matching of expect. If we narrow 
them, the test could pass. Like the following patch.

Best regards,
Wenji

[-- Attachment #2: stmtvars.patch --]
[-- Type: text/x-patch, Size: 1130 bytes --]

diff --git a/testsuite/systemtap.base/stmtvars.exp b/testsuite/systemtap.base/stmtvars.exp
index 6e950ea..ee0dcf2 100644
--- a/testsuite/systemtap.base/stmtvars.exp
+++ b/testsuite/systemtap.base/stmtvars.exp
@@ -5,7 +5,7 @@ set pc 0
 set vars ""
 spawn stap -e "probe kernel.function(\"sys_open\") {\$foo}" -p4 -vv -u
 expect {
-    -re {probe sys_open.*pc=(0x.*)\r\n} { set pc $expect_out(1,string); exp_continue }
+    -re {probe sys_open.*pc=(0x.*)\r\nsemantic} { set pc $expect_out(1,string); exp_continue }
     -re {alternatives: ([^\r\n]*) identifier [^\r\n]*\r\n} { set vars $expect_out(1,string)
         exp_continue }
     timeout { fail "$test (timeout)" }
@@ -19,7 +19,7 @@ set pc2 0
 set vars2 ""
 spawn stap -e "probe kernel.statement($pc) {\$foo}" -p4 -vv -u
 expect {
-    -re {probe sys_open.*pc=(0x.*)\r\n} { set pc2 $expect_out(1,string); exp_continue }
+    -re {probe sys_open.*pc=(0x.*)\r\nsemantic} { set pc2 $expect_out(1,string); exp_continue }
     -re {alternatives: ([^\r\n]*) identifier [^\r\n]*\r\n} { set vars2 $expect_out(1,string)
         exp_continue }
     timeout { fail "$test (timeout)" }

Re: Results of systemtap-20080517 snapshot on ppc64

[Wenji Huang]

Wenji Huang wrote:
> Srinivasa DS wrote:
>> Attaching results of systemtap-20080517 snapshot on ppc64. I have 
>> applied one interim fix(present in bug#6429) and executed the tests.
>>
>> Test Run By root on Mon May 19 15:43:30 2008
>> Native configuration is powerpc64-redhat-linux-gnu
>>
>>                 === systemtap tests ===
>> Host: Linux llm27lp1.in.ibm.com 2.6.26-rc3 #1 SMP Mon May 19 11:00:06 
>> IST 2008 ppc64 ppc64ppc64 GNU/Linux
>> Snapshot: 277f2b79b02bf69a1d72d05b06086b07bcc6a113
>>
>> FAIL: debugpath-bad (eof)
>> FAIL: PROCFS shutdown (eof)
>> FAIL: stmtvars
> [...]
> 
> I found stmtvars failed due to regexp matching of expect. If we narrow 
> them, the test could pass. Like the following patch.
> 
> Best regards,
> Wenji
> 
Sorry, not correct.  Please disregard it.

Thanks,
Wenji

Re: Results of systemtap-20080517 snapshot on ppc64

[Srinivasa DS]

Jim Keniston wrote:
> On Mon, 2008-05-19 at 18:19 +0530, Ananth N Mavinakayanahalli wrote:
>> On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
>>> Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
>>> one interim fix(present in bug#6429) and executed the tests.
>> Looks like there are a higher number of errors compared to the earlier
>> tests... probably new features?
>>
> ...
>>> FAIL: semok/nodwf01.stp
>>> FAIL: semok/nodwf02.stp
>>> FAIL: semok/nodwf03.stp
>> ^^^^^^^^^^
>> These are probably related to dwarfless
> ...
> 
> Yup.  Please try the attached patch and see if it fixes the dwarfless
> failures.

Jim, I applied the patch but still nodwf01.stp and nodwf02.stp fails.

semantic error: no match while resolving probe point 
kernel.function("sys_pipe")
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

On searching sys_pipe in /proc/kallsyms, I got this.

[root@llm27lp1 src]# grep "sys_pipe" /proc/kallsyms
c0000000000fc410 W .sys_pipe2
c0000000000fc490 W .sys_pipe

> 
> Ananth et al, can you think of any kernel functions (nm type T or t)
> where this simple mapping of ".func" to "func" would cause problems?
> 
>> Ananth
> 
> Thanks.
> Jim
> 

Re: Results of systemtap-20080517 snapshot on ppc64

[Ananth N Mavinakayanahalli]

On Mon, May 19, 2008 at 12:10:28PM -0700, Jim Keniston wrote:
> On Mon, 2008-05-19 at 18:19 +0530, Ananth N Mavinakayanahalli wrote:
> > On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
> > > Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
> > > one interim fix(present in bug#6429) and executed the tests.
> > 
> > Looks like there are a higher number of errors compared to the earlier
> > tests... probably new features?
> > 
> ...
> > 
> > > FAIL: semok/nodwf01.stp
> > > FAIL: semok/nodwf02.stp
> > > FAIL: semok/nodwf03.stp
> > ^^^^^^^^^^
> > These are probably related to dwarfless
> ...
> 
> Yup.  Please try the attached patch and see if it fixes the dwarfless
> failures.
> 
> Ananth et al, can you think of any kernel functions (nm type T or t)
> where this simple mapping of ".func" to "func" would cause problems?

If you are passing the "func" (or ".func") as a kp.symbol_name member
down to the kernel, then there won't be a problem. Otherwise, if
SystemTap is doing the lookup passing just a vaddr, then there may be
issues if its not done correctly.

Ananth

Re: dwarfless failures on ppc64

[Jim Keniston]

On Tue, 2008-05-20 at 15:55 +0530, Srinivasa DS wrote:
> Jim Keniston wrote:
> > On Mon, 2008-05-19 at 18:19 +0530, Ananth N Mavinakayanahalli wrote:
> >> On Mon, May 19, 2008 at 06:02:55PM +0530, Srinivasa DS wrote:
> >>> Attaching results of systemtap-20080517 snapshot on ppc64. I have applied 
> >>> one interim fix(present in bug#6429) and executed the tests.
> >> Looks like there are a higher number of errors compared to the earlier
> >> tests... probably new features?
> >>
> > ...
> >>> FAIL: semok/nodwf01.stp
> >>> FAIL: semok/nodwf02.stp
> >>> FAIL: semok/nodwf03.stp
> >> ^^^^^^^^^^
> >> These are probably related to dwarfless
> > ...
> > 
> > Yup.  Please try the attached patch and see if it fixes the dwarfless
> > failures.
> 
> Jim, I applied the patch but still nodwf01.stp and nodwf02.stp fails.
> 
> semantic error: no match while resolving probe point 
> kernel.function("sys_pipe")
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
> 
> On searching sys_pipe in /proc/kallsyms, I got this.
> 
> [root@llm27lp1 src]# grep "sys_pipe" /proc/kallsyms
> c0000000000fc410 W .sys_pipe2
> c0000000000fc490 W .sys_pipe
> 

Oy.  You see this problem with --kmap, but not with --kelf, right?

The problem with 'W' entries in nm listings is that some of them refer
to "real" functions and some don't.  What I see during a little research
today is... if multiple 'W' entries have the same address, none of them
refer to symbols that stap considers probeable.  If it's the only 'W'
entry with that address, stap will probe it.  I'm not sure why that is,
but could you check this out on your system?  Something like...

awk '$2=="W" {print $3}' /proc/kallsyms > weak.stp

Then edit weak.stp so you have a
	kernel.function("funcname") ?,
line for each weak function, with the result of
probe
	kernel.function("f1") ?,
	kernel.function("f2") ?,
	...
	kernel.function("fN") ?
{
	log(pp())
}
Then do
	stap -vv -p2 weak.stp > weak.p2 2>&1
and see which functions get probed.

Maybe send me weak.stp, weak.p2, and a copy of /proc/kallsyms?

Thanks.
Jim

Re: dwarfless failures on ppc64

[Roland McGrath]

> The problem with 'W' entries in nm listings is that some of them refer
> to "real" functions and some don't.  

I don't understand what you mean by that.  The distinction between W and
T (technically, between STB_WEAK and STB_GLOBAL) is really no longer
relevant by the time you're looking at /proc/kallsyms or at any linked
module's symtab (executable/kernel, DSO, or .ko).  Regardless of the
flavor of the symbol--unless it's U (undefined; technically, st_shndx is
SHN_UNDEF)--then it's an actual definition that is what references to
that symbol in the program did resolve to.

What is true is that there may be many symbols that are all aliases for
the same actual address.  Some of those symbols might be weak and others
not (also some might be local).  In the kernel there is one case where
this is commonly true, that is many weak symbols are aliases for
sys_ni_syscall (which is a stub function that returns (long)-ENOSYS).

I don't have a clear sense from what you've said of exactly how
systemtap is behaving.  If you probe sys_* for example, that will
include multiple names that resolve to the same address as
sys_ni_syscall, and so is requesting several different probes at one
address.


Thanks,
Roland

Re: dwarfless failures on ppc64

[Srinivasa DS]

Jim Keniston wrote:
>>
>> [root@llm27lp1 src]# grep "sys_pipe" /proc/kallsyms
>> c0000000000fc410 W .sys_pipe2
>> c0000000000fc490 W .sys_pipe
>>
> 
> Oy.  You see this problem with --kmap, but not with --kelf, right?

Yes, I dont see this problem with --kelf option.

> 
> The problem with 'W' entries in nm listings is that some of them refer
> to "real" functions and some don't.  What I see during a little research
> today is... if multiple 'W' entries have the same address, none of them
> refer to symbols that stap considers probeable.  If it's the only 'W'
> entry with that address, stap will probe it.  I'm not sure why that is,
> but could you check this out on your system?  Something like...
> 
> awk '$2=="W" {print $3}' /proc/kallsyms > weak.stp
> 
> Then edit weak.stp so you have a
> 	kernel.function("funcname") ?,
> line for each weak function, with the result of
> probe
> 	kernel.function("f1") ?,
> 	kernel.function("f2") ?,
> 	...
> 	kernel.function("fN") ?
> {
> 	log(pp())
> }
> Then do
> 	stap -vv -p2 weak.stp > weak.p2 2>&1
> and see which functions get probed.
> 
> Maybe send me weak.stp, weak.p2, and a copy of /proc/kallsyms?

o.k, I will send it.

Thanks
  Srinivasa DS

Re: dwarfless failures on ppc64

[Jim Keniston]

On Tue, 2008-05-20 at 15:58 -0700, Roland McGrath wrote:
> > The problem with 'W' entries in nm listings is that some of them refer
> > to "real" functions and some don't.  
> 
...
> 
> What is true is that there may be many symbols that are all aliases for
> the same actual address.  Some of those symbols might be weak and others
> not (also some might be local).  In the kernel there is one case where
> this is commonly true, that is many weak symbols are aliases for
> sys_ni_syscall (which is a stub function that returns (long)-ENOSYS).

Yes, that's exactly what I'm seeing on my system.  The weak syscall
symbols are created via the cond_syscall macro.

> 
> I don't have a clear sense from what you've said of exactly how
> systemtap is behaving.  If you probe sys_* for example, that will
> include multiple names that resolve to the same address as
> sys_ni_syscall, and so is requesting several different probes at one
> address.

Without --kelf or --kmap, stap consults only the dwarf.  Since
cond_syscall doesn't yield any dwarf, the "functions" defined thereby
don't get considered by stap.

With --kelf, the weak syscall symbols look like any other text symbols
-- we don't check STB_WEAK -- so they get considered.  This isn't good
in cases like

probe syscall.foo = kernel.function("sys_foo_weak") ?
		kernel.function("compat_sys_foo") { ... }

if sys_foo_weak is an alias for sys_ni_syscall and compat_sys_foo
actually implements the system call.

With --kmap, we currently ignore ALL weak symbols.  This is plainly
wrong, in light of the various weak symbols that correspond to non-stub
functions.

I think the following fix should provide the desired behavior, at least
wrt syscalls: For --kelf or --kmap, consider all weak symbols except
those with the same value as sys_ni_syscall.

Comments/corrections welcome.

> 
> 
> Thanks,
> Roland

Thanks very much.
Jim

Re: dwarfless failures on ppc64

[Roland McGrath]

Yeah, I was thinking of a formalism that's equivalent.  That is, an "alias
blacklist" for "sys_ni_syscall".  That means the sys_ni_syscall PC value is
disallowed for probe matches unless they are for the "sys_ni_syscall" name.


Thanks,
Roland

Re: dwarfless failures on ppc64

[Jim Keniston]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

Srinivasa, here's another patch to correct handling of weak symbols, as
described below.

On Wed, 2008-05-21 at 14:26 -0700, Jim Keniston wrote:
> On Tue, 2008-05-20 at 15:58 -0700, Roland McGrath wrote:
> > > The problem with 'W' entries in nm listings is that some of them refer
> > > to "real" functions and some don't.  
> > 
> ...
> > 
> > What is true is that there may be many symbols that are all aliases for
> > the same actual address.  Some of those symbols might be weak and others
> > not (also some might be local).  In the kernel there is one case where
> > this is commonly true, that is many weak symbols are aliases for
> > sys_ni_syscall (which is a stub function that returns (long)-ENOSYS).
> 
> Yes, that's exactly what I'm seeing on my system.  The weak syscall
> symbols are created via the cond_syscall macro.
> 
> > 
> > I don't have a clear sense from what you've said of exactly how
> > systemtap is behaving.  If you probe sys_* for example, that will
> > include multiple names that resolve to the same address as
> > sys_ni_syscall, and so is requesting several different probes at one
> > address.
> 
> Without --kelf or --kmap, stap consults only the dwarf.  Since
> cond_syscall doesn't yield any dwarf, the "functions" defined thereby
> don't get considered by stap.
> 
> With --kelf, the weak syscall symbols look like any other text symbols
> -- we don't check STB_WEAK -- so they get considered.  This isn't good
> in cases like
> 
> probe syscall.foo = kernel.function("sys_foo_weak") ?
> 		kernel.function("compat_sys_foo") { ... }
> 
> if sys_foo_weak is an alias for sys_ni_syscall and compat_sys_foo
> actually implements the system call.
> 
> With --kmap, we currently ignore ALL weak symbols.  This is plainly
> wrong, in light of the various weak symbols that correspond to non-stub
> functions.
> 
> I think the following fix should provide the desired behavior, at least
> wrt syscalls: For --kelf or --kmap, consider all weak symbols except
> those with the same value as sys_ni_syscall.
> 
> Comments/corrections welcome.
> 
> > 
> > 
> > Thanks,
> > Roland
> 
> Thanks very much.
> Jim
> 

Srini, attached are two patches:
1. powerpc_symtab.patch, which I sent you Monday
2. weak_symbols.patch, which applies atop #1

Please let me know whether these fixes resolve the powerpc failures
you're seeing.  If not, please send me your results, as previously
discussed.

Thanks.
Jim

[-- Attachment #2: powerpc_symtab.patch --]
[-- Type: text/x-patch, Size: 431 bytes --]

--- a/tapsets.cxx	2008-05-19 12:02:37.000000000 -0700
+++ b/tapsets.cxx	2008-05-19 12:02:51.000000000 -0700
@@ -4681,6 +4681,11 @@
 symbol_table::add_symbol(const char *name, Dwarf_Addr addr,
                                      Dwarf_Addr *high_addr)
 {
+#ifdef __powerpc__
+  // Map ".sys_foo" to "sys_foo".
+  if (name[0] == '.')
+    name++;
+#endif
   func_info *fi = new func_info();
   fi->addr = addr;
   fi->name = name;

[-- Attachment #3: weak_symbols.patch --]
[-- Type: text/x-patch, Size: 4134 bytes --]

--- b/tapsets.cxx	2008-05-19 12:02:51.000000000 -0700
+++ c/tapsets.cxx	2008-05-21 16:52:35.000000000 -0700
@@ -468,7 +468,7 @@
 func_info
 {
   func_info()
-    : decl_file(NULL), decl_line(-1), addr(0), prologue_end(0)
+    : decl_file(NULL), decl_line(-1), addr(0), prologue_end(0), weak(false)
   {
     memset(&die, 0, sizeof(die));
   }
@@ -478,6 +478,7 @@
   Dwarf_Die die;
   Dwarf_Addr addr;
   Dwarf_Addr prologue_end;
+  bool weak;
 };
 
 struct
@@ -551,12 +552,14 @@
   map<string, func_info*> map_by_name;
   vector<func_info*> list_by_addr;
 
-  void add_symbol(const char *name, Dwarf_Addr addr, Dwarf_Addr *high_addr);
+  void add_symbol(const char *name, bool weak, Dwarf_Addr addr,
+                                               Dwarf_Addr *high_addr);
   enum info_status read_symbols(FILE *f, const string& path);
   enum info_status read_from_elf_file(const string& path);
   enum info_status read_from_text_file(const string& path);
   enum info_status get_from_elf();
   void mark_dwarf_redundancies(dwflpp *dw);
+  void purge_syscall_stubs();
   func_info *lookup_symbol(const string& name);
   Dwarf_Addr lookup_symbol_address(const string& name);
   func_info *get_func_containing_address(Dwarf_Addr addr);
@@ -4678,8 +4681,8 @@
 }
 
 void
-symbol_table::add_symbol(const char *name, Dwarf_Addr addr,
-                                     Dwarf_Addr *high_addr)
+symbol_table::add_symbol(const char *name, bool weak, Dwarf_Addr addr,
+                                                      Dwarf_Addr *high_addr)
 {
 #ifdef __powerpc__
   // Map ".sys_foo" to "sys_foo".
@@ -4689,6 +4692,7 @@
   func_info *fi = new func_info();
   fi->addr = addr;
   fi->name = name;
+  fi->weak = weak;
   map_by_name[fi->name] = fi;
   // TODO: Use a multimap in case there are multiple static
   // functions with the same name?
@@ -4739,8 +4743,8 @@
           free(mod);
           goto done;
         }
-      if (type == 'T' || type == 't')
-        add_symbol(name, (Dwarf_Addr) addr, &high_addr);
+      if (type == 'T' || type == 't' || type == 'W')
+        add_symbol(name, (type == 'W'), (Dwarf_Addr) addr, &high_addr);
       free(name);
     }
 
@@ -4805,9 +4809,11 @@
   for (int i = 1; i < syments; ++i)
     {
       GElf_Sym sym;
-      const char *name = dwfl_module_getsym(mod, i, &sym, NULL);
-      if (name && GELF_ST_TYPE(sym.st_info) == STT_FUNC)
-        add_symbol(name, sym.st_value, &high_addr);
+      GElf_Word section;
+      const char *name = dwfl_module_getsym(mod, i, &sym, &section);
+      if (name && GELF_ST_TYPE(sym.st_info) == STT_FUNC && section != SHN_UNDEF)
+        add_symbol(name, (GELF_ST_BIND(sym.st_info) == STB_WEAK),
+                                              sym.st_value, &high_addr);
     }
   return info_present;
 }
@@ -4899,6 +4905,33 @@
   return 0;
 }
 
+// This is the kernel symbol table.  The kernel macro cond_syscall creates
+// a weak symbol for each system call and maps it to sys_ni_syscall.
+// For system calls not implemented elsewhere, this weak symbol shows up
+// in the kernel symbol table.  Following the precedent of dwarfful stap,
+// we refuse to consider such symbols.  Here we delete them from our
+// symbol table.
+// TODO: Consider generalizing this and/or making it part of blacklist
+// processing.
+void
+symbol_table::purge_syscall_stubs()
+{
+  Dwarf_Addr stub_addr = lookup_symbol_address("sys_ni_syscall");
+  if (stub_addr == 0)
+    return;
+  for (size_t i = 0; i < list_by_addr.size(); i++)
+    {
+      func_info *fi = list_by_addr.at(i);
+      if (fi->weak && fi->addr == stub_addr && fi->name != "sys_ni_syscall")
+        {
+	  list_by_addr.erase(list_by_addr.begin()+i);
+	  map_by_name.erase(fi->name);
+	  delete fi;
+	  i--;
+	}
+    }
+}
+
 void
 module_info::get_symtab(dwarf_query *q)
 {
@@ -4954,6 +4987,9 @@
   // precedes the call to query_module_symtab().  So we should never read
   // a module's symbol table without first having tried to get its dwarf.
   sym_table->mark_dwarf_redundancies(&q->dw);
+
+  if (name == TOK_KERNEL)
+    sym_table->purge_syscall_stubs();
 }
 
 module_info::~module_info()

Re: dwarfless failures on ppc64

[Srinivasa DS]

> Srini, attached are two patches:
> 1. powerpc_symtab.patch, which I sent you Monday
> 2. weak_symbols.patch, which applies atop #1
> 
> Please let me know whether these fixes resolve the powerpc failures
> you're seeing.  If not, please send me your results, as previously
> discussed.
> 

Jim
  I have applied the patch and Now testsuite/nodwf01[2][3].stp works 
fine. Thanks for the fix.

Thanks
  Srinivasa DS