[Bug translator/11347] intra-tapset visibility scoping for embedded-c functions

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From jistone at redhat dot com  2010-03-03 22:49 -------
(In reply to comment #0)
> There are cases where a tapset embedded-c function is known
> to be safe from the context of the probe that calls it, but
> cannot easily be made safe to call from arbitrary contexts.
> It would be desirable for such embedded-c functions to be
> only visible (resolvable) to probes/aliases within that tapset.

Even if hidden, "known to be safe" may be hard to prove.  If an embedded-c
function really can't be hardened, then we have to be SURE that all inputs are
fully controlled.  (And I wonder, if we know what inputs are safe anyway, why
can't the embedded-c assert that?)

> Since systemtap lacks a formal module system, this would be a
> baby step in this direction.  One simple possibility would be
> to have a policy/mechanism that treats embedded-c functions
> with a "__" prefix as being only visible to elements in the
> same tapset file as where they are defined.  (Treating
> globals, script functions, and probes as similarly visibility
> restricted might not provide any additional safety, but could
> be considered for sake of simplicity.)

An added benefit is that "internal" probe aliases could be hidden from the
suggestion list during probe syntax errors.

> mjw aux_syscalls.stp is used by multiple other tapsets
> fche cut & paste then

In cases where it's just a reuse between syscalls and syscalls2, they could be
refactored into a syscalls_foo common file.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11347

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.