headers
Anderson Lizardo | 1 Jun 2007 20:52
Picon
Gravatar

systemtap ARM port status

Hi Quentin/all,

After a quick look on the systemtap archives, I saw some references to
an ongoing systemtap ARM port, e.g. [1]. We have some interest on such
port, but we don't want to dupplicate work. So I have some questions:

- Is there any patches available we could test? We have some OMAP
boards available so we do some test on them.

- How are you running the stap scripts on the platform? We are doing
something like:

1) On host: stap -p 4 -k script.stap
2) Copy generated .ko to target
3) On target: insmod stap-module.ko

[1] http://sourceware.org/ml/systemtap/2007-q2/msg00231.html

Regards,
--

-- 
Anderson Lizardo
Open Source Mobile Research Center - OSMRC
Nokia Institute of Technology - INdT
Manaus - Brazil
Permalink | Reply | 17 comments |
headers
Quentin Barnes | 1 Jun 2007 21:33
Picon

Re: systemtap ARM port status

>Hi Quentin/all,
>
>After a quick look on the systemtap archives, I saw some references to
>an ongoing systemtap ARM port, e.g. [1]. We have some interest on such
>port, but we don't want to dupplicate work. So I have some questions:
>
>- Is there any patches available we could test? We have some OMAP
>boards available so we do some test on them.

Recently I've given a patch to support ARM in the Systemtap runtime
to Martin Hunt.  He's doing a careful review of it for me.  The
patch isn't completely there yet, but it is very, very close to
being complete.  If the ARM port work doesn't make it into the next
weekly snapshot, I'll see about a more direct access.

In the last few days I have found a couple of additional changes to
the ARM patch I sent Martin.  I'm probably going to send them to
him later today. I also am having trouble understanding a couple of
things in the runtime that's causing me trouble.  I wrote them up
and asked him about them.  I think once those things are resolved,
the ARM port of the runtime will be basically 100% there.

Note though that the ARM port work doesn't yet include all the
changes to get the testsuite to run on an ARM platform.  I'm still
working on those and will be submitting them to the list soon.

>- How are you running the stap scripts on the platform? We are doing
>something like:
>
>1) On host: stap -p 4 -k script.stap
(Continue reading)

Permalink | Reply | 16 comments |
headers
Anderson Lizardo | 1 Jun 2007 22:12
Picon
Gravatar

Re: systemtap ARM port status

On 6/1/07, Quentin Barnes <qbarnes <at> urbana.css.mot.com> wrote:
> Note though that the ARM port work doesn't yet include all the
> changes to get the testsuite to run on an ARM platform.  I'm still
> working on those and will be submitting them to the list soon.

Nice! Have you already tested some of the example .stp scripts from
the systemtap package on ARM?

> Well, for now I'm running completely native.  Yes, that's very, very
> painful to run gcc and g++ on such a board with an NFS mounted file
> system and NFS mounted swap file over loopback.  It can take four
> hours of wall time to compile and link the "stap" binary and the
> better part of a day to run the full testsuite.

How do you solve the problem of having the kernel and the modules
compiled with the same   toolchain? Do you also compile the kernel on
ARM?

> There is another group who's adding cross-target support to Systemtap:
> http://tree.celinuxforum.org/CelfPubWiki/ELC2007TechnicalShowcase?action=AttachFile&do=get&target=SystemTap_Poster.ppt
>
> I have had only limited contact with them so far.  I would like to
> have more and come up to speed on their work.

Thanks for the link. We will look into it once we have some
implementation to work on :)

> To back up a bit, where are you getting the ARM Kprobes port from?
> Is this based on Sagar and my work I posted to the ARM Linux kernel
> mailing list recently, or some other ARM Kprobes port?
(Continue reading)

Permalink | Reply | 14 comments |
headers
Quentin Barnes | 1 Jun 2007 22:46
Picon

Re: systemtap ARM port status

On Fri, Jun 01, 2007 at 04:12:58PM -0400, Anderson Lizardo wrote:
>On 6/1/07, Quentin Barnes <qbarnes <at> urbana.css.mot.com> wrote:
>>Note though that the ARM port work doesn't yet include all the
>>changes to get the testsuite to run on an ARM platform.  I'm still
>>working on those and will be submitting them to the list soon.
>
>Nice! Have you already tested some of the example .stp scripts from
>the systemtap package on ARM?

No, I've been concentrating on getting the full testsuite to pass
first.  I've just made some changes today that I think will get
virtually all the tests to pass that are expected to pass on the
kernel version and configuration I'm using.

However, one of the changes I made to loc2c-runtime.h shouldn't be
necessary, if anything, it should cause things to fail, but instead
it makes some tests now pass.  I sent some mail to Martin about it
to see if he has any ideas as to what's going on.

>>Well, for now I'm running completely native.  Yes, that's very, very
>>painful to run gcc and g++ on such a board with an NFS mounted file
>>system and NFS mounted swap file over loopback.  It can take four
>>hours of wall time to compile and link the "stap" binary and the
>>better part of a day to run the full testsuite.
>
>How do you solve the problem of having the kernel and the modules
>compiled with the same toolchain? Do you also compile the kernel on
>ARM?

I do cross-build the kernel for all my development.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Roland McGrath | 1 Jun 2007 22:49
Picon
Favicon

Re: systemtap ARM port status

> However, one of the changes I made to loc2c-runtime.h shouldn't be
> necessary, if anything, it should cause things to fail, but instead
> it makes some tests now pass.  I sent some mail to Martin about it
> to see if he has any ideas as to what's going on.

Please use this mailing list for such discussion.

Thanks,
Roland
Permalink | Reply | 10 comments |
headers
Quentin Barnes | 1 Jun 2007 23:11
Picon

Re: systemtap ARM port status

On Fri, Jun 01, 2007 at 01:49:51PM -0700, Roland McGrath wrote:
>> However, one of the changes I made to loc2c-runtime.h shouldn't be
>> necessary, if anything, it should cause things to fail, but instead
>> it makes some tests now pass.  I sent some mail to Martin about it
>> to see if he has any ideas as to what's going on.
>
>Please use this mailing list for such discussion.

Hi Roland!  I don't think we've swapped mail in some time, maybe
even going back to the gmake alpha devel mailing list back in the
'90s.

Well, gee, I think that's a real first for me.  I'm often told to
take a discussion off a mailing list to e-mail, not the other way
around!

Okay, you ask for it; you got it.  The two mails I sent to Martin
about these issues are below.

>Thanks,
>Roland

Quentin

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Fri, 1 Jun 2007 00:17:24 -0500
From: Quentin Barnes <qbarnes <at> urbana.css.mot.com>
To: Martin Hunt <hunt <at> redhat.com>
Subject: Strange failures with syscall testsuite
(Continue reading)

Permalink | Reply | 9 comments |
headers
Roland McGrath | 1 Jun 2007 23:47
Picon
Favicon

Re: systemtap ARM port status

> Hi Roland!  I don't think we've swapped mail in some time, maybe
> even going back to the gmake alpha devel mailing list back in the
> '90s.

:-)  You'll forgive me if I don't recall.  I've always been lousy at even
noticing who it is I'm conversing with in email.  And I've been actively
repressing memories associated with make for far over a decade now.  ;-)

> Well, gee, I think that's a real first for me.  I'm often told to
> take a discussion off a mailing list to e-mail, not the other way
> around!

Technical details almost always belong on a mailing list.  Then everything
is archived for future reference.  Moreover, anyone with something to
contribute can help.  It's rarely the case that exactly one person is the
one and only person who can figure out any particular problem most easily,
let alone that one can guess a priori who that person is.

The loc2c-runtime.h macros deref and store_deref are intended for dealing
with kernel addresses only.  Any appearance of "user" in their definitions
is a machine-specific implementation detail that should not concern you.
The specified use of these macros is for kernel-space addresses, with
unspecified behavior when given a user-space address.  The implementations
we have do not check that the addresses passed are kernel-space addresses,
since they don't have to.  In almost all cases, they could check (and
perhaps it would be wise for bug-catching).  But in the general case, there
is not necessarily any such check that can be made.  (The actual instance of
that case is the "4G/4G" kernel, which exists in RHEL4 for i386.)  

On machines systemtap has worked on so far, in almost all configurations
(Continue reading)

Permalink | Reply | 8 comments |
headers
Frank Ch. Eigler | 2 Jun 2007 01:53
Picon
Favicon
Gravatar

Re: systemtap ARM port status


Roland McGrath <roland <at> redhat.com> writes:

> [...]  In almost all cases, they could check [for kernel- vs
> user-space pointers].  But in the general case, there is not
> necessarily any such check that can be made.  (The actual instance
> of that case is the "4G/4G" kernel, which exists in RHEL4 for i386.)

I suspect that we will care little about preserving full function on
4G/4G if in exchange we can make systemtap more robust everywhere
else.  For one thing, I expect not to see utrace and uprobes on RHEL4,
so it will fall behind anyway.

> I would have thought that user address access in the runtime would
> just use the vanilla uaccess.h calls (get_user et al), but perhaps
> there is some __might_sleep issue in kprobes handlers.

That's exactly it.  General kprobe handlers need to be atomic.

> [...]  What it must do is gracefully goto deref_fault for any kind
> address access that does not work.  [...]

This includes detection of problems such as unaligned, unmapped,
I/O-sensitive pointer values.  Assume only that the pointer fits into
64 bits, but otherwise it might be random.

- FChE
Permalink | Reply | 1 comment |
headers
Roland McGrath | 2 Jun 2007 02:49
Picon
Favicon

Re: systemtap ARM port status

> I suspect that we will care little about preserving full function on
> 4G/4G if in exchange we can make systemtap more robust everywhere
> else.  For one thing, I expect not to see utrace and uprobes on RHEL4,
> so it will fall behind anyway.

It's easily checked by an #ifdef CONFIG_something.  So there is no reason
the macros couldn't reject user addresses on every other flavor of kernel.

Thanks,
Roland
Permalink | Reply | 0 comments |
headers
Quentin Barnes | 2 Jun 2007 05:29
Picon

Re: systemtap ARM port status

>> Hi Roland!  I don't think we've swapped mail in some time, maybe
>> even going back to the gmake alpha devel mailing list back in the
>> '90s.
>
>:-)  You'll forgive me if I don't recall.  I've always been lousy at even
>noticing who it is I'm conversing with in email.  And I've been actively
>repressing memories associated with make for far over a decade now.  ;-)

Oh, I don't fault you at all.  I'm the same way with names, just
absolutely horrible, and with e-mail too.

I think though if I dug up some of our good discussions from back
then, I'm pretty sure you'd recall one or two.

>> Well, gee, I think that's a real first for me.  I'm often told to
>> take a discussion off a mailing list to e-mail, not the other way
>> around!
>
>Technical details almost always belong on a mailing list.  Then
>everything is archived for future reference.  Moreover, anyone
>with something to contribute can help.  It's rarely the case that
>exactly one person is the one and only person who can figure out
>any particular problem most easily, let alone that one can guess a
>priori who that person is.

If Martin didn't know the answer off the top of his head, I would
have certainly taken the technical issues to the list.

>The loc2c-runtime.h macros deref and store_deref are intended for
>dealing with kernel addresses only.  Any appearance of "user" in
(Continue reading)

Permalink | Reply | 5 comments |

Gmane