aoqi@0: /* aoqi@0: * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. aoqi@0: * Copyright 2012, 2013 SAP AG. All rights reserved. aoqi@0: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. aoqi@0: * aoqi@0: * This code is free software; you can redistribute it and/or modify it aoqi@0: * under the terms of the GNU General Public License version 2 only, as aoqi@0: * published by the Free Software Foundation. aoqi@0: * aoqi@0: * This code is distributed in the hope that it will be useful, but WITHOUT aoqi@0: * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or aoqi@0: * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License aoqi@0: * version 2 for more details (a copy is included in the LICENSE file that aoqi@0: * accompanied this code). aoqi@0: * aoqi@0: * You should have received a copy of the GNU General Public License version aoqi@0: * 2 along with this work; if not, write to the Free Software Foundation, aoqi@0: * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. aoqi@0: * aoqi@0: * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA aoqi@0: * or visit www.oracle.com if you need additional information or have any aoqi@0: * questions. aoqi@0: * aoqi@0: */ aoqi@0: aoqi@0: #ifndef SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP aoqi@0: #define SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP aoqi@0: aoqi@0: #if !defined(_WINDOWS) && !defined(__APPLE__) aoqi@0: aoqi@0: aoqi@0: #include "memory/allocation.hpp" aoqi@0: #include "utilities/decoder.hpp" aoqi@0: #include "utilities/elfFile.hpp" aoqi@0: aoqi@0: /* aoqi@0: aoqi@0: On PowerPC-64 (and other architectures like for example IA64) a pointer to a aoqi@0: function is not just a plain code address, but instead a pointer to a so called aoqi@0: function descriptor (which is simply a structure containing 3 pointers). aoqi@0: This fact is also reflected in the ELF ABI for PowerPC-64. aoqi@0: aoqi@0: On architectures like x86 or SPARC, the ELF symbol table contains the start aoqi@0: address and size of an object. So for example for a function object (i.e. type aoqi@0: 'STT_FUNC') the symbol table's 'st_value' and 'st_size' fields directly aoqi@0: represent the starting address and size of that function. On PPC64 however, the aoqi@0: symbol table's 'st_value' field only contains an index into another, PPC64 aoqi@0: specific '.opd' (official procedure descriptors) section, while the 'st_size' aoqi@0: field still holds the size of the corresponding function. In order to get the aoqi@0: actual start address of a function, it is necessary to read the corresponding aoqi@0: function descriptor entry in the '.opd' section at the corresponding index and aoqi@0: extract the start address from there. aoqi@0: aoqi@0: That's exactly what this 'ElfFuncDescTable' class is used for. If the HotSpot aoqi@0: runs on a PPC64 machine, and the corresponding ELF files contains an '.opd' aoqi@0: section (which is actually mandatory on PPC64) it will be read into an object aoqi@0: of type 'ElfFuncDescTable' just like the string and symbol table sections. aoqi@0: Later on, during symbol lookup in 'ElfSymbolTable::lookup()' this function aoqi@0: descriptor table will be used if available to find the real function address. aoqi@0: aoqi@0: All this is how things work today (2013) on contemporary Linux distributions aoqi@0: (i.e. SLES 10) and new version of GCC (i.e. > 4.0). However there is a history, aoqi@0: and it goes like this: aoqi@0: aoqi@0: In SLES 9 times (sometimes before GCC 3.4) gcc/ld on PPC64 generated two aoqi@0: entries in the symbol table for every function. The value of the symbol with aoqi@0: the name of the function was the address of the function descriptor while the aoqi@0: dot '.' prefixed name was reserved to hold the actual address of that function aoqi@0: (http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES). aoqi@0: aoqi@0: For a C-function 'foo' this resulted in two symbol table entries like this aoqi@0: (extracted from the output of 'readelf -a '): aoqi@0: aoqi@0: Section Headers: aoqi@0: [ 9] .text PROGBITS 0000000000000a20 00000a20 aoqi@0: 00000000000005a0 0000000000000000 AX 0 0 16 aoqi@0: [21] .opd PROGBITS 00000000000113b8 000013b8 aoqi@0: 0000000000000138 0000000000000000 WA 0 0 8 aoqi@0: aoqi@0: Symbol table '.symtab' contains 86 entries: aoqi@0: Num: Value Size Type Bind Vis Ndx Name aoqi@0: 76: 00000000000114c0 24 FUNC GLOBAL DEFAULT 21 foo aoqi@0: 78: 0000000000000bb0 76 FUNC GLOBAL DEFAULT 9 .foo aoqi@0: aoqi@0: You can see now that the '.foo' entry actually points into the '.text' segment aoqi@0: ('Ndx'=9) and its value and size fields represent the functions actual address aoqi@0: and size. On the other hand, the entry for plain 'foo' points into the '.opd' aoqi@0: section ('Ndx'=21) and its value and size fields are the index into the '.opd' aoqi@0: section and the size of the corresponding '.opd' section entry (3 pointers on aoqi@0: PPC64). aoqi@0: aoqi@0: These so called 'dot symbols' were dropped around gcc 3.4 from GCC and BINUTILS, aoqi@0: see http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00557.html. aoqi@0: But nevertheless it may still be necessary to support both formats because we aoqi@0: either run on an old system or because it is possible at any time that functions aoqi@0: appear in the stack trace which come from old-style libraries. aoqi@0: aoqi@0: Therefore we not only have to check for the presence of the function descriptor aoqi@0: table during symbol lookup in 'ElfSymbolTable::lookup()'. We additionally have aoqi@0: to check that the symbol table entry references the '.opd' section. Only in aoqi@0: that case we can resolve the actual function address from there. Otherwise we aoqi@0: use the plain 'st_value' field from the symbol table as function address. This aoqi@0: way we can also lookup the symbols in old-style ELF libraries (although we get aoqi@0: the 'dotted' versions in that case). However, if present, the 'dot' will be aoqi@0: conditionally removed on PPC64 from the symbol in 'ElfDecoder::demangle()' in aoqi@0: decoder_linux.cpp. aoqi@0: aoqi@0: Notice that we can not reliably get the function address from old-style aoqi@0: libraries because the 'st_value' field of the symbol table entries which point aoqi@0: into the '.opd' section denote the size of the corresponding '.opd' entry and aoqi@0: not that of the corresponding function. This has changed for the symbol table aoqi@0: entries in new-style libraries as described at the beginning of this aoqi@0: documentation. aoqi@0: aoqi@0: */ aoqi@0: aoqi@0: class ElfFuncDescTable: public CHeapObj { aoqi@0: friend class ElfFile; aoqi@0: public: aoqi@0: ElfFuncDescTable(FILE* file, Elf_Shdr shdr, int index); aoqi@0: ~ElfFuncDescTable(); aoqi@0: aoqi@0: // return the function address for the function descriptor at 'index' or NULL on error aoqi@0: address lookup(Elf_Word index); aoqi@0: aoqi@0: int get_index() { return m_index; }; aoqi@0: aoqi@0: NullDecoder::decoder_status get_status() { return m_status; }; aoqi@0: aoqi@0: protected: aoqi@0: // holds the complete function descriptor section if aoqi@0: // we can allocate enough memory aoqi@0: address* m_funcDescs; aoqi@0: aoqi@0: // file contains string table aoqi@0: FILE* m_file; aoqi@0: aoqi@0: // section header aoqi@0: Elf_Shdr m_shdr; aoqi@0: aoqi@0: // The section index of this function descriptor (i.e. '.opd') section in the ELF file aoqi@0: int m_index; aoqi@0: aoqi@0: NullDecoder::decoder_status m_status; aoqi@0: }; aoqi@0: aoqi@0: #endif // !_WINDOWS && !__APPLE__ aoqi@0: aoqi@0: #endif // SHARE_VM_UTILITIES_ELF_FUNC_DESC_TABLE_HPP