dtrace discuss - Jul 2007 - Accessing variables in shared libraries

Hi,

  I''m been experimenting with libc and found a need to add a global
variable that I track in a dtrace script (OS: Solaris 10 08/07, Build 10,
SPARC), but I cannot seem to reference this variable  (either directly or via
libc.so.1`).  The following errors result:

dtrace: failed to compile script ./tt.d: line 6: floating-point constants are
not permitted

tt.d is:
-------------------------------------------------------------------
#!/usr/sbin/dtrace -Fs


pid$target:libc.so.1:set_lock_byte:entry
{
      printf("%u", libc.so.1`set_lock_count);
}
-------------------------------------------------------------------

(Note that I modified set_lock_byte also to make it traceable and to add code to
modify set_lock_count).

The declaration for the new variable, set_lock_count, is "volatile uint64_t
set_lock_count" and
it does show up in ctfdump output of libc.so.1 (and the types resolve correctly
to volatile uint64_t).  Note also that trying to reference just the variable (by
removing "libc.so.1`" also fails:

% ./tt.d -c /bin/ls
dtrace: failed to compile script ./tt.d: line 6: failed to resolve
set_lock_count: Unknown variable name
).

  What am I doing wrong?  Can libraries (with dots) not be used as
scope-resolution entities?

 Thanks,
 --S
--
This message posted from opensolaris.org

On Mon, Jul 02, 2007 at 12:40:58PM -0700, Seth Goldberg
wrote:
> dtrace: failed to compile script ./tt.d: line 6: floating-point constants
are not permitted
IIRC DTrace doesn''t support floating point types.
> dtrace: failed to compile script ./tt.d: line 6: failed to resolve
set_lock_count: Unknown variable name
> 
>   What am I doing wrong?  Can libraries (with dots) not be used as
>   scope-resolution entities?
DTrace has no knowledge of variables and types in user-land.  Instead
you have to use copyin() and friends and casts.  The result isn''t very
pretty, but it works.  I think one could add a function or operator that
interprets simple expressions in the context of the user-land process to
which the given pid provider probe refers; the expression would have to
be compiled in user-land when the provider is opened and translated into
a corresponding set of D expressions that copyin stuff as needed and
which get shoved into the actul probe body.  But that sounds like a
non-trivial project.

Nico
--

> On Mon, Jul 02, 2007 at 12:40:58PM -0700, Seth Goldberg wrote:
>> dtrace: failed to compile script ./tt.d: line 6: floating-point
constants are not permitted
>
> IIRC DTrace doesn''t support floating point types.
   That''s fine, but I wasn''t specifying a floating point
constant -- I
specified "libc.so.1`".
>
>> dtrace: failed to compile script ./tt.d: line 6: failed to resolve
set_lock_count: Unknown variable name
>>
>>   What am I doing wrong?  Can libraries (with dots) not be used as
>>   scope-resolution entities?
>
> DTrace has no knowledge of variables and types in user-land.  Instead
> you have to use copyin() and friends and casts.  The result isn''t
very
> pretty, but it works.  I think one could add a function or operator that
> interprets simple expressions in the context of the user-land process to
> which the given pid provider probe refers; the expression would have to
> be compiled in user-land when the provider is opened and translated into
> a corresponding set of D expressions that copyin stuff as needed and
> which get shoved into the actul probe body.  But that sounds like a
> non-trivial project.
   That''s also OK, if that syntax worked (unless I messed up the
syntax).  I
have no problem doing something like:

   printf("%u", *(uint64_t *)copyin(libc.so.1`set_lock_count));

  --S

On Mon, Jul 02, 2007 at 01:11:08PM -0700, Seth Goldberg
wrote:
>   That''s also OK, if that syntax worked (unless I messed up the
syntax).  I
> have no problem doing something like:
> 
>   printf("%u", *(uint64_t *)copyin(libc.so.1`set_lock_count));
Oh, I see what you mean.  I''ve no idea if DTrace supports references to
non-function symbols in user-land; I suspect it does not.

> On Mon, Jul 02, 2007 at 01:11:08PM -0700, Seth Goldberg wrote:
>>   That''s also OK, if that syntax worked (unless I messed up
the syntax).  I
>> have no problem doing something like:
>>
>>   printf("%u", *(uint64_t
*)copyin(libc.so.1`set_lock_count));
>
> Oh, I see what you mean.  I''ve no idea if DTrace supports
references to
> non-function symbols in user-land; I suspect it does not.
   That would be a bummer, but would be fine, if only the error message were 
better (and yes, I can file a bug on that if n one is aware of a preexisting, 
similar one -- a bug query didn''t reveal anything close though, but we
all
know how efficient the full text search is).

  --S

Hi Seth,
>>Oh, I see what you mean.  I''ve no idea if DTrace supports
references to
>>non-function symbols in user-land; I suspect it does not.
>>    
>>
>
>   That would be a bummer, but would be fine, if only the error message were
>better (and yes, I can file a bug on that if n one is aware of a
preexisting,
>similar one -- a bug query didn''t reveal anything close though, but
we all
>know how efficient the full text search is).
>  
>
We don''t have the user-land equivalent of the "`" kernel
scoping
operator. Currently you have to find the address and then use
that in your copyin(). I''m sure you don''t need any references
on howto
but a previous thread can be found at:

http://www.opensolaris.org/jive/message.jspa?messageID=80703

Off the top of my head I don''t know whether or not an RFE exists for
this. It sure needs to though as it gets requested quite a lot.

Jon.

Quoting Jon Haslam, who wrote the following on Mon, 2 Jul 2007:
> Hi Seth,
>
>>> Oh, I see what you mean.  I''ve no idea if DTrace supports
references to
>>> non-function symbols in user-land; I suspect it does not.
>>> 
>>
>>   That would be a bummer, but would be fine, if only the error message
were
>> better (and yes, I can file a bug on that if n one is aware of a 
>> preexisting, similar one -- a bug query didn''t reveal anything
close
>> though, but we all know how efficient the full text search is).
>> 
>
> We don''t have the user-land equivalent of the "`" kernel
scoping
> operator. Currently you have to find the address and then use
> that in your copyin(). I''m sure you don''t need any
references on howto
> but a previous thread can be found at:
>
> http://www.opensolaris.org/jive/message.jspa?messageID=80703
>
> Off the top of my head I don''t know whether or not an RFE exists
for
> this. It sure needs to though as it gets requested quite a lot.
>
  Thanks, that will at least get me past my current problem!  I''ll file
an RFE.

  --S