On Fri, Mar 25, 2011 at 09:44:40AM -0700, Roland McGrath wrote:
> It's been a while since I read Cary's proposal, and I am no longer
> likely to do much work of my own in this area. So I'll just respond at
> the high level.
>
> I like very much the essential notion of the stack being of typed
> entities with no specification of how the consumer actually implements
> it. In particular, this also brings implicit-pointer into the fold as a
> new type of a stack element, i.e. "imaginary pointer". Obviously only
> the operations that amount to addition/subtraction with an integer
> actually make sense on such a stack element. This makes the second
> operand of DW_OP(GNU_)implicit_pointer superfluous (and hence the common
> case of zero a byte smaller), since nonzero cases can just be followed
> by an appropriate DW_OP_plus_uconst or suchlike.
For DW_OP_GNU_implicit_pointer it is too late to remove the parameter now,
because e.g. GCC 4.6 has been shipped with it and several tools have support
for it already.
What we still could do is reword it based on the typed stack, say that
DW_OP_*implicit_pointer pushes an entry of a special type on the stack
and what operations are allowed with that type (from arithmetics
I think only addition of integral stack value to it (leading again to
implicit pointer type) or subtraction of two implicit pointers for the same
DIE, leading to an integral difference. With that rewording,
DW_OP_GNU_implicit_pointer could be no longer a terminal, but could appear
within the DWARF expressions.
DW_OP_implicit_pointer can of course be designed without the operand.
> As to encoding, I have a fancy idea that I discussed off the cuff at the
> Summit with Jakub and Richard, and still quite like, though I haven't
> fleshed it out any more than I did then. I hope to inspire someone else
> to actually want to implement it. It's rather more ambitious than the
> things that Jakub will just add while the rest of us sleep, so I
> wouldn't suggest that such DW_OP_GNU_* extensions be delayed for this
> plan. But perhaps it can become coherent enough and get done enough to
> seriously propose it for DWARF 5.
I view such encoding changes primarily as compression and thus IMHO
we don't need to delay any changes waiting for the compression technique
specification. We have DW_OP_call{2,4} right now as a simple compression
technique and can (and should) improve that, but in the mean time we can
just add new ops as we'd normally do.
> As I say, I'm not really working on this stuff any more except maybe for
> (as yet wholly absent) spare time. But, food for thought.
IMHO the typed stack as Cary proposed is usable as is, and as additional
bonus it is extensible, e.g. by saying that the referenced DIE doesn't
have to be just DW_TAG_base_type, but also this and that (where the
referenced DIE tags could newly be either current tags where we would give
it a particular meaning, or it could be some newly added tag, perhaps just
for that purpose) we could extend it easily.
Jakub
