1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/src/share/vm/utilities/elfFuncDescTable.hpp Wed Apr 27 01:25:04 2016 +0800
1.3 @@ -0,0 +1,149 @@
1.4 +/*
1.5 + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved.
1.6 + * Copyright 2012, 2013 SAP AG. All rights reserved.
1.7 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.8 + *
1.9 + * This code is free software; you can redistribute it and/or modify it
1.10 + * under the terms of the GNU General Public License version 2 only, as
1.11 + * published by the Free Software Foundation.
1.12 + *
1.13 + * This code is distributed in the hope that it will be useful, but WITHOUT
1.14 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1.15 + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1.16 + * version 2 for more details (a copy is included in the LICENSE file that
1.17 + * accompanied this code).
1.18 + *
1.19 + * You should have received a copy of the GNU General Public License version
1.20 + * 2 along with this work; if not, write to the Free Software Foundation,
1.21 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
1.22 + *
1.23 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
1.24 + * or visit www.oracle.com if you need additional information or have any
1.25 + * questions.
1.26 + *
1.27 + */
1.28 +
1.29 +#ifndef SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP
1.30 +#define SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP
1.31 +
1.32 +#if !defined(_WINDOWS) && !defined(__APPLE__)
1.33 +
1.34 +
1.35 +#include "memory/allocation.hpp"
1.36 +#include "utilities/decoder.hpp"
1.37 +#include "utilities/elfFile.hpp"
1.38 +
1.39 +/*
1.40 +
1.41 +On PowerPC-64 (and other architectures like for example IA64) a pointer to a
1.42 +function is not just a plain code address, but instead a pointer to a so called
1.43 +function descriptor (which is simply a structure containing 3 pointers).
1.44 +This fact is also reflected in the ELF ABI for PowerPC-64.
1.45 +
1.46 +On architectures like x86 or SPARC, the ELF symbol table contains the start
1.47 +address and size of an object. So for example for a function object (i.e. type
1.48 +'STT_FUNC') the symbol table's 'st_value' and 'st_size' fields directly
1.49 +represent the starting address and size of that function. On PPC64 however, the
1.50 +symbol table's 'st_value' field only contains an index into another, PPC64
1.51 +specific '.opd' (official procedure descriptors) section, while the 'st_size'
1.52 +field still holds the size of the corresponding function. In order to get the
1.53 +actual start address of a function, it is necessary to read the corresponding
1.54 +function descriptor entry in the '.opd' section at the corresponding index and
1.55 +extract the start address from there.
1.56 +
1.57 +That's exactly what this 'ElfFuncDescTable' class is used for. If the HotSpot
1.58 +runs on a PPC64 machine, and the corresponding ELF files contains an '.opd'
1.59 +section (which is actually mandatory on PPC64) it will be read into an object
1.60 +of type 'ElfFuncDescTable' just like the string and symbol table sections.
1.61 +Later on, during symbol lookup in 'ElfSymbolTable::lookup()' this function
1.62 +descriptor table will be used if available to find the real function address.
1.63 +
1.64 +All this is how things work today (2013) on contemporary Linux distributions
1.65 +(i.e. SLES 10) and new version of GCC (i.e. > 4.0). However there is a history,
1.66 +and it goes like this:
1.67 +
1.68 +In SLES 9 times (sometimes before GCC 3.4) gcc/ld on PPC64 generated two
1.69 +entries in the symbol table for every function. The value of the symbol with
1.70 +the name of the function was the address of the function descriptor while the
1.71 +dot '.' prefixed name was reserved to hold the actual address of that function
1.72 +(http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES).
1.73 +
1.74 +For a C-function 'foo' this resulted in two symbol table entries like this
1.75 +(extracted from the output of 'readelf -a <lib.so>'):
1.76 +
1.77 +Section Headers:
1.78 + [ 9] .text PROGBITS 0000000000000a20 00000a20
1.79 + 00000000000005a0 0000000000000000 AX 0 0 16
1.80 + [21] .opd PROGBITS 00000000000113b8 000013b8
1.81 + 0000000000000138 0000000000000000 WA 0 0 8
1.82 +
1.83 +Symbol table '.symtab' contains 86 entries:
1.84 + Num: Value Size Type Bind Vis Ndx Name
1.85 + 76: 00000000000114c0 24 FUNC GLOBAL DEFAULT 21 foo
1.86 + 78: 0000000000000bb0 76 FUNC GLOBAL DEFAULT 9 .foo
1.87 +
1.88 +You can see now that the '.foo' entry actually points into the '.text' segment
1.89 +('Ndx'=9) and its value and size fields represent the functions actual address
1.90 +and size. On the other hand, the entry for plain 'foo' points into the '.opd'
1.91 +section ('Ndx'=21) and its value and size fields are the index into the '.opd'
1.92 +section and the size of the corresponding '.opd' section entry (3 pointers on
1.93 +PPC64).
1.94 +
1.95 +These so called 'dot symbols' were dropped around gcc 3.4 from GCC and BINUTILS,
1.96 +see http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00557.html.
1.97 +But nevertheless it may still be necessary to support both formats because we
1.98 +either run on an old system or because it is possible at any time that functions
1.99 +appear in the stack trace which come from old-style libraries.
1.100 +
1.101 +Therefore we not only have to check for the presence of the function descriptor
1.102 +table during symbol lookup in 'ElfSymbolTable::lookup()'. We additionally have
1.103 +to check that the symbol table entry references the '.opd' section. Only in
1.104 +that case we can resolve the actual function address from there. Otherwise we
1.105 +use the plain 'st_value' field from the symbol table as function address. This
1.106 +way we can also lookup the symbols in old-style ELF libraries (although we get
1.107 +the 'dotted' versions in that case). However, if present, the 'dot' will be
1.108 +conditionally removed on PPC64 from the symbol in 'ElfDecoder::demangle()' in
1.109 +decoder_linux.cpp.
1.110 +
1.111 +Notice that we can not reliably get the function address from old-style
1.112 +libraries because the 'st_value' field of the symbol table entries which point
1.113 +into the '.opd' section denote the size of the corresponding '.opd' entry and
1.114 +not that of the corresponding function. This has changed for the symbol table
1.115 +entries in new-style libraries as described at the beginning of this
1.116 +documentation.
1.117 +
1.118 +*/
1.119 +
1.120 +class ElfFuncDescTable: public CHeapObj<mtInternal> {
1.121 + friend class ElfFile;
1.122 + public:
1.123 + ElfFuncDescTable(FILE* file, Elf_Shdr shdr, int index);
1.124 + ~ElfFuncDescTable();
1.125 +
1.126 + // return the function address for the function descriptor at 'index' or NULL on error
1.127 + address lookup(Elf_Word index);
1.128 +
1.129 + int get_index() { return m_index; };
1.130 +
1.131 + NullDecoder::decoder_status get_status() { return m_status; };
1.132 +
1.133 + protected:
1.134 + // holds the complete function descriptor section if
1.135 + // we can allocate enough memory
1.136 + address* m_funcDescs;
1.137 +
1.138 + // file contains string table
1.139 + FILE* m_file;
1.140 +
1.141 + // section header
1.142 + Elf_Shdr m_shdr;
1.143 +
1.144 + // The section index of this function descriptor (i.e. '.opd') section in the ELF file
1.145 + int m_index;
1.146 +
1.147 + NullDecoder::decoder_status m_status;
1.148 +};
1.149 +
1.150 +#endif // !_WINDOWS && !__APPLE__
1.151 +
1.152 +#endif // SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP
