Issue 090503.1: DW_OP_linkage_name and DW_OP_linkage_name_ptr operations
Background
----------
Historically, an attribute named DW_AT_MIPS_linkage_name (a vendor
extension) has been used by a number of implementations to handle
certain problems representing C++ information in DWARF. Briefly, the
value of the attribute is a string (usually a mangled name) which
the DWARF consumer is expected to resolve at debug time.
About two years ago Chris Quenelle of Sun proposed to integrate this
capability into DWARF proper as an attribute named DW_AT_linkage_name.
The reason for needing such an attribute has long been unclear to me.
When I asked Chris why it was needed and how it was expected to be
used, he replied (email of 5/2/2007)
"The simplest case where this is necessary is when the name of
symbol is known at compile time, but the symbol is not guaranteed to
be present in the final a.out. But if the symbol *is* present,
you want to associate a DIE with that address. In many
link environments, relocations must be resolved or errors
and/or warnings result.
"At one time, the normal Sun implementation used the location attribute
(with a relocated address) when the target symbol is guaranteed to be
present, and used a mangled name when it was not guaranteed."
He elaborated later (5/3/2007):
"On Solaris, there is no way to tell the linker: "relocate this if the
following symbol is available otherwise, leave it as zero".
If that feature existed in our linker (with the right combination
of relocation types) then we wouldn't need this attribute."
I suggested to him that a better formulation might be to define a
DW_OP_linkage_name expression operation that would be interpreted
in much the same way. This operation could be used as the location
description of a DW_AT_location attribute to achieve the same effect
as the original DW_AT_MIPS_linkage_name. In addition, it might be
useful in the context of other attributes and/or in combination with
more general DWARF expressions.
Chris liked this suggestion. But he soon left the committee and the
matter never got pursued further.
Proposal
--------
At the end of Section 2.5.1.3, add the following new operations:
14. DW_OP_linkage_name
The DW_OP_linkage_name operation determines the value of the
following null terminated string using the symbol table of the
containing object file and pushes that value on the stack. If
the symbol is not defined in the object file, the effect is
implementation-defined.
*This operator provides a means to defer evaluation of an object
symbol until debug time. This provides a means to make a reference
using an object symbol that may or may not be present in the
object without using relocations which generally must be resolved
else errors and/or warnings result.*
15. DW_OP_linkage_name_ptr
The DW_OP_linkage_name_ptr operation determines the value of a
name found at the following offset in the DWARF string section
using the symbol table of the containing object file and pushes
that value on the stack. If the symbol is not defined in the
object file, the effect is implementation-defined.
*This operator is the same as DW_OP_linkage_name except the string
to be resolved is stored in the DWARF string section rather than
immediately following the operation in the DWARF expression. Note
that the size of the offset in the string section depends on the
format in use as described in Section 7.4.*
In Section 7.4, add the following line in the table of bullet 3:
DW_OP_linkage_name_ptr offset in .debug_str
In Section 7.7.1, add the following entries in Figure 24: DWARF
operation encodings (preceeding DW_OP_lo_user):
DW_OP_linkage_name 0xa0 1 null terminated string
DW_OP_linkage_name_ptr 0xa1 1 4- or 8-byte offset
in .debug_str section
Discussion
----------
This proposal deliberately leaves the meaning of an undefined symbol
as undefined rather than specifying a fall-back value of zero. This
allows a consumer to immediately abort expression evaluation when
an undefined name is encountered and proceed directly with fall-back
processing. If this occurs in the context of a larger expression (eg
symbol + offset expression) this could allow more user friendly
handling on the part of a consumer. Or, a consumer can simply use
a fall-back value of zero and keep going. This is a quality of
implementation matter which DWARF need not dictate.
---
Rejected. See replacement Issue 090715.1
