[Bug translator/13315] New: @cast() should also accept an object file to extract typedie info

[Bug translator/13315] New: @cast() should also accept an object file to extract typedie info

[fche at redhat dot com]

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

             Bug #: 13315
           Summary: @cast() should also accept an object file to extract
                    typedie info
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


The translator supports a couple of syntaxes to generate/find debuginfo
for @cast expressions.  One that's missing is

    @cast(value,"typename","/path/to/object/file")

where said file is to be used directly as a source of elf/dwarf, rather
than interpreted as a header.  For example:

% cat foo.c
#include <stdlib.h>
struct foo { int bar; int zoo; };
void main ()
{ 
  struct foo* bar = malloc(sizeof (struct foo));
}
% gcc -g -c foo.c
% ls -al foo.o
% readelf -w foo.o | less  # to inspect struct foo decl is indeed there
% stap -p4 -e 'probe begin { println(@cast(0,"foo","./foo.o")->bar) }'
semantic error: type definition 'foo' not found: identifier '@cast' at
<input>:1:23
        source: probe begin { println(@cast(0,"foo","./foo.o")->bar) }
                                      ^
oops

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

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[rrakus at fedoraproject dot org]

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

Roman Rakus <rrakus at fedoraproject dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rrakus at fedoraproject dot
                   |                            |org

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

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[jistone at redhat dot com]

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

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> 2011-10-18 18:43:54 UTC ---
I see two things going on here.  First, @cast isn't treating the relative path
correctly, because of this check:

> bool
> is_user_module(const std::string &m)
> {           
>   return m[0] == '/' && m.rfind(".ko", m.length() - 1) != m.length() - 3;
> }

That's checking only for a leading slash, so a relative path is treated as a
kernel module.  We'll have to check other callers, but I think it would work to
make it like this instead:
>   return (m.find('/') != string::npos) && !endswith(m, ".ko");

The second thing I notice, even with a fully-specified path, is that we appear
to only work with user modules that are ET_EXEC or ET_DYN.  With the ET_REL
foo.o, I get:

> $ stap -p2 -e 'probe begin { println(@cast(0,"foo","/home/jistone/bugs/pr13315/foo.o")->bar) }'
> WARNING: cannot find module /home/jistone/bugs/pr13315/foo.o debuginfo: Callbacks missing for ET_REL file
> WARNING: cannot find module /home/jistone/bugs/pr13315/foo.o debuginfo: Callbacks missing for ET_REL file
> WARNING: cannot find module /home/jistone/bugs/pr13315/foo.o debuginfo: Callbacks missing for ET_REL file
> WARNING: cannot find module /home/jistone/bugs/pr13315/foo.o debuginfo: Callbacks missing for ET_REL file
> semantic error: type definition 'foo' not found: identifier '@cast' at <input>:1:23
>         source: probe begin { println(@cast(0,"foo","/home/jistone/bugs/pr13315/foo.o")->bar) }
>                                       ^
> Pass 2: analysis failed.  Try again with another '--vp 01' option.


And a side note, since I overheard that rrakus was first trying to get @cast
working in a probe process.mark.  We've always filled in the @cast module
automatically for .function probes, and I happened to notice recently that we
weren't doing this for .mark, so I fixed that in commit 40a0c64e.  This commit
is too recent to be in a release yet though.  It also still requires debuginfo
for that binary, which isn't necessarily present for SDT use.

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

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[rrakus at fedoraproject dot org]

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

--- Comment #2 from Roman Rakus <rrakus at fedoraproject dot org> 2011-10-22 13:55:07 UTC ---
When using binary with debuginfo (not stripped) it works, with mentioned commit
40a0c64e.

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

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[rrakus at fedoraproject dot org]

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

--- Comment #3 from Roman Rakus <rrakus at fedoraproject dot org> 2011-10-22 16:36:48 UTC ---
@cast(value,"typename")
with mentioned commit also works with separate debuginfo.
The bug could be closed I guess.

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

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[jistone at redhat dot com]

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

--- Comment #4 from Josh Stone <jistone at redhat dot com> 2011-10-22 20:38:45 UTC ---
Thanks for testing!

(In reply to comment #3)
> The bug could be closed I guess.

I think we can keep this still bug open for the .o usage that Frank suggests.

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

[Bug core/13315] @cast() should also accept an object file to extract typedie info

[gobisha6355 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13315

shanjay <gobisha6355 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|translator                  |core
           Assignee|systemtap at sourceware dot org    |unassigned at sourceware dot org
            Product|systemtap                   |netresolve
           Severity|normal                      |critical

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13315

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|core                        |translator
           Assignee|unassigned at sourceware dot org   |systemtap at sourceware dot org
            Product|netresolve                  |systemtap

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/13315] @cast() should also accept an object file to extract typedie info

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13315

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal

-- 
You are receiving this mail because:
You are the assignee for the bug.