RFR(S): 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables

[Volker Simonis]

On PowerPC-64 (and other architectures like for example IA64) a
pointer to a function is not just a plain code address, but a pointer
to a so called function descriptor (see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES).
This fact is also reflected in the ELF ABI for PowerPC-64. This small
changes adds support for ELF function descriptor tables to the current
ELF decoder:

http://cr.openjdk.java.net/~simonis/webrevs/8019929/

On architectures like x86 or SPARC, the ELF symbol table contains the
start address and size of an object. So for example for a function
object (i.e. type FUNC) the symbol table's value field directly
represents the starting address and the size field the size of a
function. On PPC64 however, the symbol table's value field only
contains an index into a PPC64 specific .opd (official procedure
descriptors) section, while the size field still holds the size of the
corresponding function. In order to get the actual start address of a
function, it is necessary to read the corresponding function
descriptor entry in the .opd section at the corresponding index and
extract the start address from there.

This change extends the current HotSpot ELF utilities to support the
.opd (official procedure descriptors) section on PPC64 platforms. It
does this by adding a new field m_funcDesc_table of type
ElfFuncDescTable to the ElfFile class. The m_funcDesc_table is
initialized in the ElfFile::load_tables() in the same way like the
symbol table members by parsing the corresponding .opd section if it
is available.

The ElfSymbolTable::lookup() method is changed on PPC64 to take an
extra ElfFuncDescTable argument. If running on PPC64, this argument is
used to do the extra level of indirection through the function
description table to get the real start address associated with a
symbol.

This change also slightly improves the implementation of
ElfSymbolTable::lookup(). Before, the method always iterated over all
symbols in the symbol table and returned the one with the highest
address below the requested addr argument. This not only could take a
significant amount of time for big libraries, it could also return
bogus symbols for addresses which were not really covered by that
symbol table at all. The new versions additionally uses the symbol
table's st_size field to verify that the requested addr argument is
indeed within the range covered by the corresponding symbol table
entry. If so, the search is stopped and the symbol is returned
immediately.

Thank you and best regards,
Volker