Re: systemtap ARM port status

[Roland McGrath <roland at redhat dot com>]

> 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
(all but 4g/4g), the relationship between user and kernel address spaces is
such that using the deref macro works the same for either kind of address.
A particular implementation of the runtime's user_* functions for a
particular machine and configuration might rely on this fact and use those
macros for some reason.  Martin will have to answer about those particulars.
I have only been directly involved with the loc2c-runtime.h code.  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.

For a new machine, the deref/store_deref macros can be implemented however
works best or is easiest for you to write and maintain, and need only
support access to a kernel-space address.  What it must do is gracefully
goto deref_fault for any kind address access that does not work.  On
configurations where kernel and user address values are disjoint, it is
certainly kosher for it to goto deref_fault for a user address.


Thanks,
Roland