1960N/A * Copyright (c) 2002, 2010, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 1472N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 1472N/A * or visit www.oracle.com if you need additional information or have any 0N/A/** <P> An implementation of the JVMDebugger interface which talks to 0N/A windbg and symbol table management is done in Java. </P> 0N/A <P> <B>NOTE</B> that since we have the notion of fetching "Java 0N/A primitive types" from the remote process (which might have 0N/A different sizes than we expect) we have a bootstrapping 0N/A problem. We need to know the sizes of these types before we can 0N/A fetch them. The current implementation solves this problem by 0N/A requiring that it be configured with these type sizes before they 0N/A can be fetched. The readJ(Type) routines here will throw a 0N/A RuntimeException if they are called before the debugger is 0N/A configured with the Java primitive type sizes. </P> */ 0N/A // Symbol lookup support 0N/A // This is a map of library names to DLLs 0N/A // C/C++ debugging support 0N/A // windbg native interface pointers 0N/A //-------------------------------------------------------------------------------- 0N/A // Implementation of Debugger interface 0N/A /** <P> machDesc may not be null. </P> 0N/A <P> useCache should be set to true if debugging is being done 0N/A locally, and to false if the debugger is being created for the 0N/A purpose of supporting remote debugging. </P> */ 0N/A // Need to override default checkAlignment because we need to 0N/A "Trying to read at address: " 0N/A // Cache portion of the remote process's address space. 0N/A // Fetching data over the socket connection to dbx is slow. 0N/A // Might be faster if we were using a binary protocol to talk to 0N/A // dbx, but would have to test. For now, this cache works best 0N/A // if it covers the entire heap of the remote process. FIXME: at 0N/A // least should make this tunable from the outside, i.e., via 0N/A // the UI. This is a cache of 4096 4K pages, or 16 MB. The page 0N/A // size must be adjusted to be the hardware's page size. 0N/A // (FIXME: should pick this up from the debugger.) 0N/A // FIXME: add instantiation of thread factory 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A // Close all open DLLs 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A /** From the Debugger interface via JVMDebugger */ 0N/A // FIXME: CDebugger is not yet supported for IA64 because 0N/A // of native stack walking issues. 0N/A /** From the SymbolLookup interface via Debugger and JVMDebugger */ 0N/A /** From the SymbolLookup interface via Debugger and JVMDebugger */ 0N/A /** From the Debugger interface */ 0N/A //-------------------------------------------------------------------------------- 0N/A // Implementation of ThreadAccess interface 0N/A /** From the ThreadAccess interface via Debugger and JVMDebugger */ 0N/A // with windbg we can't make out using handle 0N/A //---------------------------------------------------------------------- 0N/A // Overridden from DebuggerBase because we need to relax alignment 0N/A // constraints on x86 0N/A // FIXME: allow this to be configurable. Undesirable to add a 0N/A // dependency on the runtime package here, though, since this 0N/A // package should be strictly underneath it. 0N/A // utils.checkAlignment(address, jlongSize); 0N/A //-------------------------------------------------------------------------------- 0N/A // Internal routines (for implementation of WindbgAddress). 0N/A // These must not be called until the MachineDescription has been set up. 0N/A /** From the WindbgDebugger interface */ 0N/A /** From the WindbgDebugger interface */ 0N/A /** From the WindbgDebugger interface */ 0N/A /** From the WindbgDebugger interface */ 0N/A //-------------------------------------------------------------------------------- 0N/A // Thread context access 0N/A // remove path part, if any. 0N/A //-------------------------------------------------------------------------------- 0N/A /** From the Debugger interface */ 0N/A /** From the WindbgDebugger interface */ 0N/A //-------------------------------------------------------------------------------- 0N/A // Internals only below this point 0N/A "already attached to a process!";
0N/A }
// else fallthru... 0N/A // The DLL can be null because we use this to search through known 0N/A // DLLs in HotSpotTypeDataBase (for example) 0N/A /** This reads bytes from the remote process. */ 1960N/A * sawindbg.dll depends on dbgeng.dll which itself depends on 1960N/A * dbghelp.dll. We have to make sure that the dbgeng.dll and 1960N/A * dbghelp.dll that we load are compatible with each other. We 1960N/A * load both of those libraries from the same directory based 1960N/A * on the theory that co-located libraries are compatible. 1960N/A * On Windows 2000 and earlier, dbgeng.dll and dbghelp.dll were 1960N/A * not included as part of the standard system directory. On 1960N/A * systems newer than Windows 2000, dbgeng.dll and dbghelp.dll 1960N/A * are included in the standard system directory. However, the 1960N/A * versions included in the standard system directory may not 1960N/A * be able to handle symbol information for the newer compilers. 1960N/A * We search for and explicitly load the libraries using the 1960N/A * following directory search order: 1960N/A * - dir named by DEBUGGINGTOOLSFORWINDOWS environment variable 1960N/A * - various "Debugging Tools For Windows" program directories 1960N/A * If SA is invoked with -Dsun.jvm.hotspot.loadLibrary.DEBUG=1, 1960N/A * then debug messages about library loading are printed to 1960N/A // First place to search is co-located with sawindbg.dll in 1960N/A // second place to search is specified by an environment variable: 1960N/A // The third place to search is the install directory for the 1960N/A // "Debugging Tools For Windows" package; so far there are three 1960N/A // name variations that we know of: 1960N/A // The last place to search is the system directory: 1960N/A "': directory does not exist.");
1960N/A // this search directory doesn't exist so skip it 1960N/A // both files exist so we have a match 1960N/A // At least one of the files does not exist; no warning if both 1960N/A // don't exist. If just one doesn't exist then we don't check 1960N/A // loadLibraryDEBUG because we have a mis-configured system. 1960N/A "': dbgeng.dll and dbghelp.dll were not found.");
1960N/A // at least one of the files wasn't found anywhere we searched 1960N/A mesg =
"dbgeng.dll and dbghelp.dll cannot be found. ";
1960N/A mesg =
"dbgeng.dll cannot be found (dbghelp.dll was found). ";
1960N/A mesg =
"dbghelp.dll cannot be found (dbgeng.dll was found). ";
1960N/A "Please search microsoft.com for 'Debugging Tools For Windows', " +
1960N/A "and either download it to the default location, or download it " +
1960N/A "to a custom location and set environment variable " +
1960N/A "'DEBUGGINGTOOLSFORWINDOWS' to the pathname of that location.");
1960N/A // NOTE: The order of loads is important! If we load dbgeng.dll 1960N/A // first, then the dependency - dbghelp.dll - will be loaded 1960N/A // from usual DLL search thereby defeating the purpose! 0N/A // Now, load sawindbg.dll 0N/A // where do I find '.exe', '.dll' files? 0N/A // where do I find '.pdb', '.dbg' files? 0N/A // mostly, debug files would be find where .dll's, .exe's are found. 0N/A // should we parse DLL symbol table in Java code or use 0N/A // Windbg's native lookup facility? By default, we use 0N/A // native lookup so that we can take advantage of '.pdb' 0N/A // files, if available. 0N/A // helper called lookupByAddress0