[Bug translator/19952] New: listing mode should list dwarf-annotated types

[Bug translator/19952] New: listing mode should list dwarf-annotated types

[fche at redhat dot com]

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

            Bug ID: 19952
           Summary: listing mode should list dwarf-annotated types
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

As per bug #13664, some stap script level variables have an inferred dwarf type
tag associated with them, when they were last assigned from a $context var.  We
should list that type name in the stap -L mode, instead or in addition to
":long".

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

[Bug translator/19952] listing mode should list dwarf-annotated types

[jistone at redhat dot com]

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

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> ---
There's a little ambiguity in the type domains, especially with "long".  At
least with a context $var it's somewhat clear that it's the target language's
"long", but with "foo:long" this isn't clear.

But now that I write this, I think that particular case doesn't really matter,
as they're just numbers and we widen it anyway.  So consider this comment just
a braindump of a dismissable concern.  Something like "string" might have been
more tricky, e.g. C++'s is shown without even the std namespace "$s:string",
but it can only be assigned as a pointer, or possibly a reference, so
"foo:string" should definitely be systemtap string.

Printing the dwarf type *in addition* seems like the safer choice, if we can
devise a way that doesn't itself look like a compound type.

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