[Bug tapsets/13878] New: c++ stl decomposition functions

[Bug tapsets/13878] New: c++ stl decomposition functions

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13878

             Bug #: 13878
           Summary: c++ stl decomposition functions
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


In addition to $var$$, it would be helpful if the tapset included some
libstdc++ structure-traversal functions, so that scripts like this may be
written:

void foo (std::string bar) { }
stap -e 'probe ... function("foo") { if (cpp_string($bar) == "yo") ... }

This may in turn require @cast() to be able to take c++ templated types,
as in 

function cpp_string(ptr) {
  return @cast(ptr, "std::basic_string<char, std::char_traits<char>,
std::allocator<char> >")->_M_dataplus->_M_p
}

or even @cast("..., "std::string"), neither of which appear to work currently.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13878] c++ stl decomposition functions

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13878

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> 2012-03-20 16:33:40 UTC ---
(In reply to comment #0)
> This may in turn require @cast() to be able to take c++ templated types,
> as in 
> 
> function cpp_string(ptr) {
>   return @cast(ptr, "std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >")->_M_dataplus->_M_p
> }
> 
> or even @cast("..., "std::string"), neither of which appear to work currently.

This should work already, thanks to bug 12136.  However, note that the default
module for a @cast without context is "kernel", which will normally have no
knowledge of std::string et al. :)

So the @cast will need a third argument, some module with debuginfo which
contains std::string.  Even better if we could use @cast header support, but
that currently only knows how to do kbuild or plain gcc.  (Bug 10055 comment 1
sort of mentions this, but we probably need a new bug for compiler options and
userspace languages other than C.)

Back on the $subject, I wonder whether stl types are fixed enough for us to
have general functions?  I'm thinking especially between --std versions, might
the layout of these objects vary?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13878] c++ stl decomposition functions

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13878

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> 2012-03-20 19:24:44 UTC ---
> This should work already, thanks to bug 12136.  However, note that the default
> module for a @cast without context is "kernel" 

Ah.  The error message should include a hint to that effect.


> [...]
> Back on the $subject, I wonder whether stl types are fixed enough for us to
> have general functions?  I'm thinking especially between --std versions, might
> the layout of these objects vary?

That's why nature invented @defined().
Whether it's enough for everything, I dunno.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13878] c++ stl decomposition functions

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13878

--- Comment #3 from Josh Stone <jistone at redhat dot com> 2012-03-20 19:39:38 UTC ---
(In reply to comment #2)
> > This should work already, thanks to bug 12136.  However, note that the default
> > module for a @cast without context is "kernel" 
> 
> Ah.  The error message should include a hint to that effect.

It currently says:
  semantic error: type definition 'std::string' not found: [location]

Would it suffice to amend like this?  ... not found in "$module": ...

> > Back on the $subject, I wonder whether stl types are fixed enough for us to
> > have general functions?  I'm thinking especially between --std versions, might
> > the layout of these objects vary?
> 
> That's why nature invented @defined().
> Whether it's enough for everything, I dunno.

I'm not sure how @defined would help.  It can let you vary your cpp_string()
implementation depending on the chosen module, but my concern is with knowing
the layout of the user's incoming ptr, for which we have no type info.  Bug
13664 could make that pretty snazzy though...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13878] c++ stl decomposition functions

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13878

--- Comment #4 from Josh Stone <jistone at redhat dot com> 2012-03-20 20:09:48 UTC ---
(In reply to comment #3)
> Would it suffice to amend like this?  ... not found in "$module": ...

commit 4583161b546f7d5371e10d875a03825f564a30c0
Author: Josh Stone <jistone@redhat.com>
Date:   Tue Mar 20 13:04:18 2012 -0700

    PR13878: Mention the module in @cast "not found" message

    To help understand when @cast fails to find a type, mention the module
    that was searched.  This may already hinted by the e->tok source
    location, but stating the module explicitly is a useful hint if the user
    left the module field to be implicitly filled in.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.