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

[Vladimir Kozlov]

Volker,

It looks fine to me except #ifdef pollution.

I think ElfSymbolTable::lookup() should always take ElfFuncDescTable 
argument and you need ElfFuncDescTable always defined.
In ElfSymbolTable::lookup() you can check funcDescTable for null instead 
of ifdefs.
The only place we can keep #ifdef is m_funcDesc_table setting in 
ElfFile::load_tables().
ElfFuncDescTable class's methods are not so big to ifdef them.

But others may have different opinion.

Thanks,
Vladimir

On 12/3/13 9:39 AM, Volker Simonis wrote:
> 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
>