DWARF Standard


090503.1 Ron Brender DW_OP_linkage_name and DW_OP_linkage_name_ptr operations Enhancement Rejected Ron Brender


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.


At the end of Section, 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

        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


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

All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.