Re: Systemtap testsuite report for arm architecture

["Bruno Abinader" <bruno dot abinader at openbossa dot org>]

Hi again,

On Thu, Mar 27, 2008 at 1:19 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
>  "Bruno Abinader" <bruno.abinader@openbossa.org> writes:
>
>  > We at INdT made a few tests using systemtap on maemo devices (arm
>  > architecture). For these results, it was used the Systemtap snapshot
>  > 20081201 and elfutils 0.131.
>
>  Thank you for your valuable analysis.

Thank you for the answers. We are still studying systemtap testcaes so
many of your questions are still not answered. We forgot to mention
that there are instructions available on systemtap's wiki about how to
run these tests inside maemo devices. Links are below:

- http://sourceware.org/systemtap/wiki/SystemtapMaemo
- http://sourceware.org/systemtap/wiki/SystemtapMaemoBenchmark

First link teaches how to compile and pack systemtap for the devices,
and the second is about kernel compilation and testcases execution.
There are also contributions made by Eugene Teo available on these
links (July 2007):

- http://lists.maemo.org/pipermail/maemo-developers/2007-July/010868.html
- http://lists.maemo.org/pipermail/maemo-developers/2007-July/010869.html

>
>
>  > Results for 20080201:
>  >                  === systemtap Summary ===
>  >
>  >  # of expected passes            367
>  >  # of unexpected failures        68
>  >  # of unexpected successes       1
>  >  # of expected failures          153
>  >  # of known failures             6
>  >  # of untested testcases         15
>  >  # of unsupported tests          4
>  >  runtest completed at Fri Feb  1 15:28:08 2008
>
>  Would you mind emailing the dejagnu systemtap.sum file to
>  dejazilla@elastic.org?  Can you also try a newer snapshot of systemtap
>  (or from cvs )?

Sorry for that, we'll hope to do that for the next systemtap evaluation.

>
>
>  >  FAIL: cmd_parse6: unexpected EOF
>  >  -----------------------------------------------------
>  >  This test gives EOF because systemtap was unable to evaluate the
>  >  following sentence:
>  >  stap -c '(((a=42+7)); echo "The answer is $a")' -e 'probe begin {}'
>  >  The correct output is: "The answer is 49" but console output shown "The
>  >  answer is" without number.
>
>  What a strange test - appears to assume $SHELL=bash.  Will fix.

That's right. Maemo uses busybox in order to save space, thus giving
lesser capabilities for the shell. There should be a way for the
script to detect it.

>
>
>
>  >  FAIL: systemtap.base/deref.stp startup (eof)
>  >  ---------------------------------------------------------------
>  >  Fails to compile on ARM. Looks like a bug on ARM-specific read/write
>  >  memory addresses code. [...]
>
>  Someone with access to arm hardware (or a good simulator) will need to
>  port this stuff.
>
>
>
>  >  FAIL: backtrace - could not build modules
>  >  FAIL: args - could not build modules
>  >  FAIL: pid - could not build modules
>  >  --------------------------------------------------
>  >  stap was unable to find "systemtap_test_module2" on ARM.
>
>  I wonder why.
>
>
>  >  'backtrace' stap output:
>  >  [...]
>
> >  module("systemtap_test_module2").function("yyy_char").return
>  >  semantic error: no match while resolving probe point
>
>  Another porting issue, I suspect.
>
>
>
>  >  FAIL: buildok/eighteen.stp
>  >  -------------------------------------
>  >  CONFIG_AUDITSYSCALL was disabled in kernel compilation, which is not
>  >  available for ARM. Can be ignored.
>
>  Perhaps the test suite should look at include/linux/autoconf.h or the
>  kernel .config and expose the active CONFIG_<> flags to the tcl code.
>  Then this test could be xfail'd.
>
>
>
>  >  FAIL: buildok/seventeen.stp
>  >  ----------------------------------------
>  >  Fails with the following output:
>  >  semantic error: cannot relocate user-space dso (?) address: identifier
>  >  '$write_fifo_fops' at seventeen.stp:8:19
>
>  This should be fixed in more recent systemtap code.

That's fine, we're planning to do another review with newer systemtap
code and will post results as soon as we get everything done.

>
>
>  >  FAIL: buildok/nfs-all-probes.stp
>  >  FAIL: buildok/nfsd-all-probes.stp
>  >  ----------------------------------------------
>  >  Kernel modules nfs, sunrpc and others come from the package
>  >  rx-34-kernel-modules-extra. [...]
>
>  This test could benefit from the .config-parsing.
>
>
>
>  >  FAIL: buildok/vfs-all-probes.stp
>  >  [...]
>
> >  ------------------------------------------
>  >  All these tests fail with a "semantic error: failed to retrieve return
>  >  value location" error, due to missing return value locations support for
>  >  ARM in elfutils backend. This issue also affects all LKET modules, so
>  >  LKET is not working on ARM.
>
>  That should be noted as an elfutils bug (pls open one on
>  bugzilla.redhat.com).

Thanks, I've created a bug, link is below:

- https://bugzilla.redhat.com/show_bug.cgi?id=440059

As the list doesn't mention any 'other' platform, I've assumed
Fedora's Rawhide with arm7 architecture.

>
>  >  FAIL: systemtap.samples/ioblocktest.stp shutdown (eof)
>  >  ---------------------------------------------------------------------------------
>  >  Test initially fails because it depends on direct block I/O activity.
>  >  This can be triggered by reading directly from /dev/mtdblock4 using
>  >  "dd". [...]
>
>  What is the maemo compiler version?  Later ones do better with debuginfo
>  correctness.

Maemo's compiler version is:

sbox-arm-linux-gcc (GCC) 3.4.4 (release) (CodeSourcery ARM 2005q3-2)

>
>
>
>  >  FAIL: transok/tval-opt.stp
>  >  ------------------------------------
>  >  Fails with the following output:
>  >  semantic error: Expecting symbol or array index expression: identifier
>  >  '$keycode' at <input>:1:58
>  >  semantic error: unexpected type: identifier '$keycode' at <input>:1:44
>  >  semantic error: failed to retrieve location attribute for local
>  >  'keycode' (dieoffset: 0x9ec239): identifier '$keycode' at <input>:1:44
>
>  This one may be fixed in more recent code.
>
>
>  > [...]
>
> >  FAIL: conversions.stp 0xffffffff (6)
>  >  FAIL: conversions.stp 0xffffffffffffffff (6)
>  >  -----------------------------------------------------
>  >  This test depends on architecture-specific memory addressing
>  >  conventions. There is no special treatment for ARM in this case. [...]
>
>  Can you suggest another address range based on arm linux kernel memory
>  layout?
>
>
>
>  >  []s, and sorry for the long mail!
>
>  No problem - thank you!
>
>
>  - FChE
>



-- 
Bruno de Oliveira Abinader
Mobile Linux Software (MLS) / Instituto Nokia de Tecnologia (INdT)