This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: variables in scopes
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Vara Prasad" <prasadav at us dot ibm dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Thu, 14 Apr 2005 08:13:33 -0700
- Subject: RE: variables in scopes
I believe it will be possible in our language to express bad
pointers, regardless of syntax. If we accept this the issue
becomes: how do we make such problems safe and debuggable.
I believe the memory portal would allow scripts to recover
safely from the "disaster" scripts Vara suggests below.
Anticipating Frank's perspective, you might not even need
the portal, since we already have a special trap handler
to catch bad pointer dereferences.
I agree with others that asking people to use something
different than C syntax for navigating C data structures
from the kernel is the wrong way to go.
Brad
-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Vara Prasad
Sent: Thursday, April 14, 2005 7:12 AM
To: Jim Keniston
Cc: Frank Ch. Eigler; SystemTAP
Subject: Re: variables in scopes
Jim Keniston wrote:
>On Wed, 2005-04-13 at 15:58, Frank Ch. Eigler wrote:
>
>
>
> ....
>
>& lvalue
>* pointer
>
>
I definitely think we will be heading in the wrong direction if we let
systemtap scripts use full blown "C" pointers directly. It is o.k to let
them traverse datastructures using -> and . constructs but not full
blown pointers. In my view allowing full pointers is asking for disaster
in terms of the safety of the code.
>functions calls -- to three types of functions:
>a) SystemTap auxiliary functions (as currently parsed)
>b) C functions in the context of the probed function
>c) C functions (set off by yacc/lex escapes such as %% or %{...%}) that
>are copied from the .stp file to the module's .c file.
>
>I am certainly willing to limit it to this and then see what we have to
>add later. (c) above should buy us a lot of wiggle room, although it
>leaves a hole in semantics checking.
>
>
>
>>- FChE
>>
>>
>
>Jim
>
>
>
>