Hi!

This patch on top of
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html
and
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01723.html
implements parts of Cary's typed DWARF stack proposal:
http://www.dwarfstd.org/doc/040408.1.html

As I said in my GCC Summit talk, currently we just give up on
any floating point/_Decimal*/__int128 and for 32-bit targets even
long long expressions, as those can't be represented in DWARF4,
while var-tracking has all that often available.

As we are quickly running out of available extension opcodes
in the GNU namespace (unless we go back to 0xeX range, with
this proposal we have just 7 left and it would be good
to reserve at least one such opcode as multiplexor for new
opcodes (DW_OP_GNU_multiplex whose first operand would be uleb128
extended opcode number followed by its arguments) and perhaps another
one to signal some location expression compression technique using
abbreviation table), I've chosen to add just those that are useful
for GCC and consumers of its debug info right now.
DW_OP_GNU_const{1,2,4,8}_type would allow us to save one byte, but that
doesn't seem worth wasting 4 opcodes in GNU namespace (the standard
has more, so it could add them).  Similarly, as GCC currently
never emits DW_OP_xderef*, I've not added DW_OP_GNU_xderef_type.
And DW_OP_GNU_readonly is something I have no idea how to get out
of var-tracking.  DW_OP_stack_value or DW_OP_implicit_value is
implicitly readonly, and for REGs/MEMs I don't think var-tracking
allows us to find out if changing this REG or MEM is the right way
to change the value of the variable, it is at each spot just
one of possibly more locations holding the value.

The added
DW_OP_GNU_const_type
DW_OP_GNU_regval_type
DW_OP_GNU_deref_type
DW_OP_GNU_convert
match (sans _GNU) what is written in the proposal and one extra
DW_OP_GNU_reinterpret
opcode has been added, which is like DW_OP_GNU_convert (so just one uleb128
argument with base type offset), but it is not a conversion (say
convert a floating point value to integer), but reinterpretation of
the bits (VIEW_CONVERT_EXPR-like, or store one value into a union, read
another value from another union field).

Some small problems on the producer side were caused by the base
type references being uleb128 instead of 4 byte number (in particular,
size of say DW_AT_location block depends on the offset number being
already known, but to compute offset numbers one has to know the sizes;
solved both for these and debug info size reasons by making sure
base types referenced from such ops are present very early in the CU
and can be sized and layed out early - base types shouldn't have
attributes with location expressions anyway - and the earlier they
are in the CU, the smaller the uleb128s are), but having them all
4 byte would be too large, so I actually like them being uleb128s.

On the consumer side I expect if a consumer decides to support these,
it implements the DWARF stack as pairs of some type id (or
encoding/byte size) and union of the supported typed fields.

Attached is also a guality testcase that shows some of what it can
e.g. represent, with the exception of two vars for -m32 in second routine
it actually has a location expression for all vars on both x86_64
and i?86.  If anyone from the debug info consumer crowd is interested,
I could post the assembly files for -m{32,64} -g -dA -O2.

	Jakub