[Bug translator/26129] New: The @cast(variable, type) operator failing to find type information

[Bug translator/26129] New: The @cast(variable, type) operator failing to find type information

[wcohen at redhat dot com]

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

            Bug ID: 26129
           Summary: The @cast(variable, type) operator failing to find
                    type information
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

When running the systemtap examples a number of them would fail because
@(variable, type) operator would fail to find the type definitions.  This can
be observed with the simple sizeof.stp example (there are about ten other
examples that appear to fail due to this @cast issue):

$ sudo stap  testsuite/systemtap.examples/general/sizeof.stp int
[sudo] password for wcohen: 
semantic error: type definition 'int' not found in '': operator '@cast' at
/usr/share/systemtap/tapset/sizeof.stpm:4:9
        source:     ( & @cast(0, @type) [1] )
                        ^
        in expansion of macro: operator '@cast_sizeof' at
testsuite/systemtap.examples/general/sizeof.stp:15:6
        source:             @cast_sizeof(@1))
                            ^

Pass 2: analysis failed.  [man error::pass2]

The expected result is:

$ sudo ../install/bin/stap  testsuite/systemtap.examples/general/sizeof.stp int
type int byte-size: 4


A git bisect was done and the following commit was identified as causing the
failure: 


00ee19ff030f665df7e087a579f39105256a0253 is the first bad commit
commit 00ee19ff030f665df7e087a579f39105256a0253
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Mon May 4 17:33:51 2020 -0400

    PR25841 for dwarf probes: permit functions to use $context constructs

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

[Bug translator/26129] The @cast(variable, type) operator failing to find type information

[fche at redhat dot com]

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

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

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

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
@cast operator no longer defaults to "kernel" in case of a missing third
(module) parameter.  So this test case should either not use that alternative
any more, or hard-code "kernel" on line 13 of the example.

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

[Bug translator/26129] The @cast(variable, type) operator failing to find type information

[wcohen at redhat dot com]

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

--- Comment #2 from William Cohen <wcohen at redhat dot com> ---
Okay, simple enough to fix the examples @cast to include the needed "kernel"
argument. What about the sizeof.stpm:

@define cast_sizeof(type) %(
    ( & @cast(0, @type) [1] )
%)

should that include a "kernel" argument in there to keep the previous
semantics?

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

[Bug translator/26129] The @cast(variable, type) operator failing to find type information

[fche at redhat dot com]

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

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
> What about the sizeof.stpm:

I'd leave that one alone, so it can be used from normal functions/probes in
some proper new-style dwarfy context.


I suspect I should have included a --compatible=4.2 logic in the translator to
put the "kernel" default in for older usage though.

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