dtrace discuss - Feb 2008 - Changing function arguments or result

(This question is about the Mac OS X version of dtrace, but I''m told
they don''t do anything special there.)

I can use copyout() to modify the program''s memory (with -w) and thus
patch up errant functions'' memory in user space. But what if I need to
patch a function''s return value, or its arguments? Arg0 etc. are
read-only ("operator = can only be applied to a writable variable"),
so I can''t assign to them. The same appears to apply to uregs[]. That
seems to severely restrict the kinds of interventions I am allowed, particularly
on register-based architectures.

Cheers
  -- perry


--
This message posted from opensolaris.org

This isn''t possible today, but it''s an RFE that has existed
for quite
awhile.
Take a look at this old mail thread:

   http://opensolaris.org/jive/thread.jspa?messageID=36261&#36261

- ahl

On Feb 18, 2008, at 7:48 PM, Perry The Cynic wrote:
> (This question is about the Mac OS X version of dtrace, but I''m
told
> they don''t do anything special there.)
>
> I can use copyout() to modify the program''s memory (with -w) and  
> thus patch up errant functions'' memory in user space. But what if
I
> need to patch a function''s return value, or its arguments? Arg0
etc.
> are read-only ("operator = can only be applied to a writable  
> variable"), so I can''t assign to them. The same appears to
apply to
> uregs[]. That seems to severely restrict the kinds of interventions  
> I am allowed, particularly on register-based architectures.
>
> Cheers
>  -- perry
>
>
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Assigning to uregs[] (as per RFE 5005776) seems useful but much inferior to
assigning to arg* (or args[]). Why be architecture-specific when you can be
source-specific?

On a more general note, being new to DTrace I read the "how I patched a
system call for an errant third party program" description and deduced that
"fixing" programs (not just observing how they fail :-) is one of its
design purposes. Am I mistaken, or is changing parameters/return values just one
of those things that hasn''t been done yet (but lines up properly with
the intended use of the feature)?

Thanks
  -- perry


--
This message posted from opensolaris.org

Perry The Cynic wrote:
> Assigning to uregs[] (as per RFE 5005776) seems useful but much inferior
> to assigning to arg* (or args[]). Why be architecture-specific when you
> can be source-specific?
> 
> On a more general note, being new to DTrace I read the "how I patched
a
> system call for an errant third party program" description and deduced
> that "fixing" programs (not just observing how they fail :-) is
one of
> its design purposes. Am I mistaken, or is changing parameters/return
> values just one of those things that hasn''t been done yet (but
lines up
> properly with the intended use of the feature)?

I think you''re wrong in deducing this. DTrace is first and foremost an 
observability tool; once you''ve found where a problem lies in a 
program/piece of code, you need to fix the code, not apply some kind of 
over-engineered band-aid*.

Michael

(*)lest I be misunderstood: I don''t see DTrace as overengineered. Using
it
for "fixing" programgs would be.
-- 
Michael Schuster        Sun Microsystems, Inc.
http://blogs.sun.com/recursion

> > On a more general note, being new to DTrace I read the "how I
patched a
> > system call for an errant third party program" description and
deduced
> > that "fixing" programs (not just observing how they fail :-)
is one of
> > its design purposes. Am I mistaken, or is changing parameters/return
> > values just one of those things that hasn''t been done yet
(but lines up
> > properly with the intended use of the feature)?
> 
> 
> I think you''re wrong in deducing this. DTrace is first and
foremost an
> observability tool; once you''ve found where a problem lies in a 
> program/piece of code, you need to fix the code, not apply some kind of 
> over-engineered band-aid*.
You know, I can understand if band-aids are not part of DTrace''s goal,
but it is in a unique position to do some really cool things. Fixing broken code
at the source is definitely best but may not be an option, especially for
third-party, closed-source apps. Even for in-house code, a band-aid at critical
times could be a lifesaver. Plus it would make a wonderful prototyping tool.

$.02
--
This message posted from opensolaris.org