This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Tapset porting to 2.6.38
Hi,
We spent time looking at generated code to debug some "pure" code but dereferencing was such a myth internally (bad habit from C) that we never had a deeper look :-(
I meant union and not enum. Of course, now that I know better, I can't figure out the example again. Not even sure it was related to V4L2 even if this is where we have mostly used it like: "@cast($q, "videobuf_queue")->bufs[@cast($b, "v4l2_buffer")->index]->baddr"
I will keep looking in our drivers related to V4L2
Regards
Fred
Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-----Original Message-----
From: David Smith [mailto:dsmith@redhat.com]
Sent: Tuesday, March 15, 2011 5:15 PM
To: Turgis, Frederic
Cc: systemtap@sourceware.org
Subject: Re: Tapset porting to 2.6.38
On 03/14/2011 05:40 PM, Turgis, Frederic wrote:
> Very interesting patch for us.
> We did not dig that much as we were convinced that we could only
> dereference pointers. Therefore, we thought we could not do something
> like @cast(sock, "inet_sock")->sk->__sk_common->skc_daddr because in
> C, it would be pointer->sk.__sk_common.skc_addr (so no pointer as soon
> as
you want __sk_common).
That has confused people before. In systemtap script language, you always just use '->'.
If you want to see the C source code that systemtap produces for __ip_sock_daddr(), you can do the following:
# stap -vp3 -e 'probe begin { print(__ip_sock_daddr(0)) }'
> On top of that, we had bad experience in the past with derefencing
> V4L2 structures but we finally discovered issue was more related to the use of "enum".
Hmm, I'm not aware of any issues we have with enums. Have you got an example?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)