[Bug translator/13664] New: support dwarf types for stap variables

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

             Bug #: 13664
           Summary: support dwarf types for stap variables
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: jistone@redhat.com
    Classification: Unclassified


It sure would be nice if stap variables could carry some rich type information.
 We know how to do complex accesses on $vars, but as soon as you assign it to a
local variable, it becomes just a long (equivalent to int64_t).  Any further
access requires a nest of @casts, generally failing expressiveness and DRY
principles.

This is hard to do fully.  The greatest challenge may be trying to decide
whether two DWARF types are equivalent -- just ask Mark and Roland about DWARF
compression.  But with a few simplifications (aka designed limitations), I
think we can feasibly add more useful type functionality.

My suggestions:

* Represent the type of a variable as basically a pair of dwflpp and Dwarf_Die
(or even just the die offset).

* Do this only for pointer/array types.  Numeric types can become longs as
normal.  For structs, one can use '&' to get a pointer instead.
- This means in our runtime implementation, we can still carry these values
around in int64_t memory.

* Punt on type comparisons altogether.  If type resolution brings together
variables from different typedies, e.g. in arithmetic or in separate
assignments to the same variable, demote the result to long.

* Support dwarf types only for locals.  For global values and map indexes,
demote to long just as we do now.  Authors could still @cast to a local to
regain the type later.

* If a dwarf-typed variable is passed as a function parameter, treat it like
template/generic programming and create a separate instance of that function.
- Functions with explicit typing like :long and :string could use :dwarf for
this special behavior.  Embedded-C functions shouldn't be allowed to use :dwarf
though.  (You're writing C, so cast it yourself, guru.)
- This function-forking will probably duplicate a lot, but we already have
mechanisms to recombine dupes in pass-3.

There are probably still complications that I'm not thinking of, that we may
not know how to deal with.  If we can sweep those under the rug as unsupported
cases, that's fine for now.  When in doubt, reduce to long, and we can try to
enhance more later.

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