== location hacking ==

I've long thought we should have some fancy stuff for doing clever things
with DWARF location expressions (actually DWARF expressions, value
expressions, and location expressions, which are a family of related
things).

I always imagined this would be implemented only in C++ and thought about a
few details but not really much concrete.  

A little background:

 * a ''DWARF expression'' is the basic stack machine program that can
   compute a value of target address size
 * a ''value expression'' is what's used for '''DW_AT_frame_base'''.  It
   can be a DWARF expression or it can be a register name, which is a more
   compact encoding of the program to simply fetch the register's value.
   What it yields is a value, not the address or register location of a value.
 * a ''location expression'' is the most general thing.  When it's a simple
   DWARF expression, that yields a memory address that is the location
   where the value of interest (e.g. a variable) is stored.  It can also be
   a composite using '''DW_OP_piece''' or '''DW_OP_bit_piece'''.  The
   components of such a composite can be read-only values that are computed
   and marked with '''DW_OP_const_value''', or read-only literals from
   '''DW_OP_implicit_value''', or virtual pointers from
   '''DW_OP_GNU_implicit_pointer'''.  The whole thing is the location of
   the value of interest, some of which might be immutable, or some of
   which might be mutable in memory or registers (or parts of them).
 * a ''relative location expression'' is what's used in
   '''DW_AT_data_member_location''': it is like the tail of a location
   expression, but it's defined only relative to some other location

Some of the things this would do:

 * internalize DWARF expressions, value expressions, location
   expressions, and relative location expressions into C++ objects that
   know which kind of thing they are
 * optimize expressions statically
 * combine a relative location with a location to produce a new location
 * partially resolve values based on available dynamic information,
   up to full resolution if all register and memory data is available
 * map an optimized and partially resolved location into the terms of
   another kind of evaluator

The dynamic information includes the results of CFI in a given PC context.
If the PC is known, then CFI becomes static location information.  In
something like a systemtap probe or a GDB conditional breakpoint
expression, this can be resolved statically and combined to produce an
optimized location.

I imagine the internalized and optimized form being a simple kind of
expression tree produced from the stack machine program, where each node
has some operand nodes and an operation that's still represented with a
'''DW_OP_*''' opcode.  There could then be interfaces for visiting the
nodes of the tree.  In systemtap, this would be used to replace the
existing '''loc2c.c''' code with something that turns an optimized and
partially-resolved location calculation into the systemtap translator's own
expression tree form to be translated directly.

For dynamic kinds of uses, there would be interfaces to have a location
object say what kind of information it needed to reduce to a simpler form,
such as CFI, register values, memory values.  Then as much as is
immediately available can be supplied to make it simpler for the next phase
of use.  In fully-dynamic situations, that would include supplying all
current register and memory data needed to resolve to a final mutable
location in registers or memory or a final value.