[Dwarf-Discuss] address values in constant forms

Roland McGrath roland at redhat.com
Fri Dec 11 15:50:52 PST 2009

> I don't think DW_OP_addr conveys enough information to do what you
> want.  For instance, what if a target has multiple pointer sizes?
> Or worse, multiple pointer encodings?

Theoretically you can do all this with DW_OP_piece or DW_OP_bit_piece.
Unless you mean different pointer encodings that require different kinds of
platform-specific address adjustments.  I don't really know what that would
mean, but regardless, to me it is just bending over backwards to find an
intractable case.  I don't see the existence of any given intractable case
as a worthwhile reason to punt on large classes of tractable cases.

> You're never going to get all the way with this; there are always
> going to be optimized out values that are not practical to compute
> in DWARF.  I'd like to see why this case is important enough to
> bend over backwards to accomodate it.

I don't think that removing an apparently-arbitrary limitation on the forms
DW_AT_const_value can use constitutes bending over backwards.  As to the
complex cases with DW_OP_piece and DW_OP_stack_value, well, it is of course
up to a compiler implementation to decide how hard to work on which cases.
By your logic, we never should have added DW_OP_stack_value and
DW_OP_implicit_value in the first place.  You're certainly free not to use
them in your compiler.  I'm interested in a compiler that does everything
as well as we can think of ways to do it.  It's another question how much
work to put into that (and for my part, that question is up to Alexandre
for practical purposes).  But the discussion here is on what the DWARF
specification can do so as not to constrain compiler implementors in these

> Suppose you remove the static qualifier from your array `i'.  How
> do we then compute these values?

It depends on how the code is compiled, of course.  For the obvious code
(given no evident constraints on bar's expectations on the pointers passed
to it), that makes these cases simpler (in the sense that they do not
involve the subject of address constants at all), as they involve only
locations and values computed relative to a register or the CFA.  For cases
where the "i" array itself is optimized away, that is a different subject
that also has nothing to do with address constants.  (I do happen to have a
possible proposal in mind for such cases, but that is not a subject I am
raising today.)


More information about the Dwarf-Discuss mailing list