dtrace discuss - Jul 2007 - Where can I find the documentation about CTF?

---------- Forwarded message ----------
From: ?? Tao Jie <eulertao at gmail.com>
Date: 2007-7-11 ??1:32
Subject: Where can I find the documentation about CTF?
To: opensolaris-discuss at opensolaris.org, "ug-shosug at
opensolaris.org" <
ug-shosug at opensolaris.org>

Dear all:

I''m reading the source code now and puzzled with the CTF (Compact C
Type
Format) and its APIs.
I searched in the docs.sun.com and blogs.sun.com. Nothing useful found :(

Where can I find the documentation about CTF?

Thanks in advance.



Regards
TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070711/1cf8d03c/attachment.html>

You can search for "Compact C Type Format" at
http://cvs.opensolaris.org/source/

e.g. the header files:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ctf.h

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ctf_api.h

Rayson



On 7/11/07, ?? Tao Jie <eulertao at gmail.com>
wrote:
> I''m reading the source code now and puzzled with the CTF (Compact
C Type Format) and its APIs.
> I searched in the docs.sun.com and blogs.sun.com. Nothing useful found :(
>
> Where can I find the documentation about CTF?
>
> Thanks in advance.
>
>
>
> Regards
> TJ
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

Is there any more detailed documentation for this?

2007/7/11, Rayson Ho <rayrayson at gmail.com>:
>
> You can search for "Compact C Type Format" at
> http://cvs.opensolaris.org/source/
>
> e.g. the header files:
>
>
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ctf.h
>
>
>
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ctf_api.h
>
> Rayson
>
>
>
> On 7/11/07, ?? Tao Jie <eulertao at gmail.com> wrote:
> > I''m reading the source code now and puzzled with the CTF
(Compact C Type
> Format) and its APIs.
> > I searched in the docs.sun.com and blogs.sun.com. Nothing useful found
> :(
> >
> > Where can I find the documentation about CTF?
> >
> > Thanks in advance.
> >
> >
> >
> > Regards
> > TJ
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
> >
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070712/d83beedf/attachment.html>

On Thu, Jul 12, 2007 at 01:21:05AM +0800, ???? Tao Jie wrote:
> Is there any more detailed documentation for this?
Not really. The source is your best reference. Is there some aspect in
particular you have questions about?

regards
john

in ctf.h
struct ctf_file {
 ctf_strs_t ctf_str[2]; /* array of string table base and bounds */

Why do there exist two string tables?


2007/7/12, John Levon <john.levon at sun.com>:
>
> On Thu, Jul 12, 2007 at 01:21:05AM +0800, ???? Tao Jie wrote:
>
> > Is there any more detailed documentation for this?
>
> Not really. The source is your best reference. Is there some aspect in
> particular you have questions about?
>
> regards
> john
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070724/7a1a6004/attachment.html>

On Tue, Jul 24, 2007 at 11:40:43PM +0800, ???? Tao Jie wrote:
> in ctf.h
> struct ctf_file {
> ctf_strs_t ctf_str[2]; /* array of string table base and bounds */
> 
> Why do there exist two string tables?
I could be wrong here, but I believe this is a size optimization that''s
not
actually used. The idea being that you could add CTF entries into a CTF
container that referred to an external string table (CTF_STRTAB_1) instead
of duplicating the string in the CTF container itself (CTF_STRTAB_0). I
don''t
think we actually do that anywhere in Solaris right now.

regards
john

> > in ctf.h
> > struct ctf_file {
> > ctf_strs_t ctf_str[2]; /* array of string table base and bounds */
> > 
> > Why do there exist two string tables?
> 
> I could be wrong here, but I believe this is a size optimization
that''s not
> actually used. The idea being that you could add CTF entries into a CTF
> container that referred to an external string table (CTF_STRTAB_1) instead
> of duplicating the string in the CTF container itself (CTF_STRTAB_0). I
don''t
> think we actually do that anywhere in Solaris right now.
> 
> regards
> john
Correct: I left space for that because many of the strings in the CTF data
will match strings in the program symbol table (.symtab).  Therefore I was
leaving myself the option of adding another pass to CTF generation which
could find such strings and leverage the fact that the object already had
those strings in its ELF file and so we didn''t need another copy of
them.
At some point someone can revisit how much of a benefit that would be.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

Dear, Mike and John:

Thank you for your help :)

Another problem  ><
in ctf_types.c
int ctf_type_encoding(ctf_file_t *fp, ctf_id_t type, ctf_encoding_t *ep)
{
........
 switch (LCTF_INFO_KIND(fp, tp->ctt_info)) {
 case CTF_K_INTEGER:
  data = *(const uint_t *)((uintptr_t)tp + increment);
........
}

tp is a variable of ctf_type_t
increment is set by ctf_get_ctt_size(), and its value should
be sizeof(ctf_type_t)
Am I right?

if so, (in a 32bit x86 architecuture)
------------------------------ <-- tp (pointer to the start of ctf_type_t)
|         ctt_name      |
------------------------------
|  ctt_info  |     _u     |
------------------------------
|        ctt_lsizehi      |
------------------------------
|        ctt_lsizelo      |
------------------------------ <-- tp+increment
|        ????????       |
------------------------------
since the tp is casted to be an unsigned int, add increment to tp makes tp
point to the end of the ctf_type_t
and then cast it to a pointer to uint_t and dereference that address
I think the dereference value is ????????, anything that is not related with
the orignal tp, and it is very strange.
Is there anything wrong in my deduction?


Regards
TJ


2007/7/25, Michael Shapiro <mws at
zion.eng.sun.com>:
>
>
> > > in ctf.h
> > > struct ctf_file {
> > > ctf_strs_t ctf_str[2]; /* array of string table base and bounds
*/
> > >
> > > Why do there exist two string tables?
> >
> > I could be wrong here, but I believe this is a size optimization
that''s
> not
> > actually used. The idea being that you could add CTF entries into a
CTF
> > container that referred to an external string table (CTF_STRTAB_1)
> instead
> > of duplicating the string in the CTF container itself (CTF_STRTAB_0).
I
> don''t
> > think we actually do that anywhere in Solaris right now.
> >
> > regards
> > john
>
> Correct: I left space for that because many of the strings in the CTF data
> will match strings in the program symbol table (.symtab).  Therefore I was
> leaving myself the option of adding another pass to CTF generation which
> could find such strings and leverage the fact that the object already had
> those strings in its ELF file and so we didn''t need another copy
of them.
> At some point someone can revisit how much of a benefit that would be.
>
> -Mike
>
> --
> Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070725/0f45f461/attachment.html>

On Wed, Jul 25, 2007 at 04:24:25PM +0800, ???? Tao Jie wrote:
> int ctf_type_encoding(ctf_file_t *fp, ctf_id_t type, ctf_encoding_t *ep)
> {
> ........
> switch (LCTF_INFO_KIND(fp, tp->ctt_info)) {
> case CTF_K_INTEGER:
>  data = *(const uint_t *)((uintptr_t)tp + increment);
> ........
> }
> 
> since the tp is casted to be an unsigned int, add increment to tp makes tp
> point to the end of the ctf_type_t
> and then cast it to a pointer to uint_t and dereference that address
> I think the dereference value is ????????, anything that is not related
with
> the orignal tp, and it is very strange.
The pointer returned points directly in the CTF buffer, and that has the extra
details of each type directly after the ctf_type_t (or ctf_stype_t!). Have a
look at ctfdump''s read_types(), that should make it clear
what''s happening.

May I ask, is there a particular reason you''re looking at the CTF code?

regards
john