Re: Any existing extensions to describe ELF symbol index values?

[adunsmui at ca dot ibm dot com]

Dave Anderson wrote:
>Al, I don't think such an object-format-specific thing would be
>appropriate for the dwarf3 spec.

>Nothing prevents you from adding such a thing as a vendor
>extension, and that is the direction I would suggest (of course
>DW_AT_symbol_index would not be the right name as it has no
>vendor indication: see the naming conventions for vendor
>extensions).

Dave,

I agree that DW_AT_IBM_elf_symbol_index would be a better name.

My question was really about prior art for vendor extensions.
I knew about your MIPS extension, and intend to use that (with
an equivalent IBM name) for the general mechanism for storing
mangled symbol names.  As our actual executable is in another
format, and we are using the ELF packaging for the DWARF data
in a separate file, only those symbols required to connect the
two (typically at the CU level) are required to be in the ELF
symbol table.  I'm having to do my own plumbing (and debug linker),
so an extension to support this may be worth while.

For the normal folks using ELF for their objects and executables,
does the lack of the possibility of a direct connection to the
symbol table simply reflect a limitation in the ELF format and ld
(new relocation type required) or is there a good reason to have
multiple copies of the symbol name text?

This does raise another issue:  what is the standard approach that
is recommended when reusing another vendor's extension?  In ascending
levels of effort, one could:
  - use it as-is (for example, via existing libdwarf support)
  - use a different extension name, explicitly defined to be the
    original extension id by name
  - use a different extension name and index, and dual path the
    library code
  - use different extension name, index, and code

The issue really is not related to originality - one would always
want to credit the author (and/or company) which produced the original
extension.

The possibility exists that over time the different vendors could
take what is nominally the same extension in different directions.
Implementing the extensions via in a common library such as libdwarf
helps minimize this problem.

As with many problems in life, this problem would be minimized by good
communications.   It helps when the original vendor extension is well
documented (like SGI's), especially when this documentation follows
the format of the new DWARF 3 spec.

>Aside:
>  We completed action on all proposals for the dwarf3
>  spec at the last meeting.
>  It's finished, aside from review and a public comment period.

Congratulations and thanks to all the DWARF committee members... it's
been a long haul.  I'm looking forward to the final review draft.

Al

z/OS C/C++ Compiler Development: Debug Data Architect
External phone: 905-413-3315                  Tie-Line: 8-969-3315
External mail: adunsmui@us.ibm.com   Internal VM files:  adunsmui at
torolab2