arm64 kprobes/systemtap support progress

[David Smith]

On 11/20/2014 10:14 AM, William Cohen wrote:
> I did a quick look over of the current results and categorized most of
> them below.

... stuff deleted ...

> Uprobes support not available:
> 
> FAIL: bad-code

The above doesn't need uprobes, but it does to a user backtrace. (Or
does a user backtrace require uprobes?)

> FAIL: callee (simple - probing .callee(foo))
> FAIL: callee (multicalls - probing main .callees)
> FAIL: callee (inlined - probing main .callees)
> FAIL: callee (extern - probing main .callees)
> FAIL: callee (reloc - probing shlib foo .callees)
> FAIL: pr16719 (user - can't start stap)
> FAIL: sdt_misc wildcard (0) V1_uprobe
> FAIL: sdt_misc wildcard (0) V2_uprobe
> FAIL: sdt_misc wildcard (0) V3_uprobe
> FAIL: stmt_inlines (probing error, expected 4, got 0)
> FAIL: stmt_rel (bio_init sanity check)
> FAIL: ./systemtap.examples/general/py2example build
> FAIL: ./systemtap.examples/memory/last_100_frees build

I fixed all the above by adding 'uprobes_p' checks to the test cases.

> FAIL: 64_BIT_UTRACE_SYSCALL_ARGS shutdown (eof)

The above one isn't a uprobes problem. That test only uses utrace, not
uprobes (it passes on ia64 for instance, which has utrace but not uprobes).

> plt support not impletement:
>
> FAIL: listing_mode (untested probe type: process(number).plt)
> FAIL: listing_mode (untested probe type: process(number).plt.return)
> FAIL: listing_mode (untested probe type: process(number).plt(string))
> FAIL: listing_mode (untested probe type: process(number).plt(string).return)

I've fixed these, you should get KFAILs now.

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