Examples with LibraryDataSource com.ibm.j9ddr.corereaders.LibraryDataSource used on opensource projects

Example 1 with LibraryDataSource

use of com.ibm.j9ddr.corereaders.LibraryDataSource in project openj9 by eclipse.

the class ELFDumpReader method readModules.

/**
 * Read all modules in the core file, where "modules" = the executable and all
 * shared libraries. Put the executable into _executable and the libraries without
 * the executable into _modules.
 * <p>
 * Find libraries by two methods: iterating through all the segments in the core
 * file looking for which are libraries and iterating through the debug information
 * within the executable. We may find the executable either on disk, within the
 * core file as one of the loaded segments, or appended to the core file by
 * library collections. Consolidate the list of libraries that we find from the
 * debug information with the list from the core file to build the best list possible.
 * <p>
 * When constructing the module objects, use the best available data. This means using
 * the section header information from the collected libraries if present since this
 * is always more reliable than that in the core file.
 *
 * @throws IOException
 */
/* In a second comment to avoid it appearing in hovertext
	 * 
	 * This method is called under at least two completely different circumstances:
	 * 
	 * Circumstance 1 - called during library collection when there are not yet any collected libraries
	 * appended to the core file. In this case all that is really wanted is a list of the 
	 * names of the libraries to guide the collection but this method does not discriminate and 
	 * constructs everything possible, reading section header tables and symbol tables and so on. 
	 * In this case the aim is to return the most complete list of modules, examining both the 
	 * modules within the core file and the list that can be found from the debug data in the 
	 * executable. 
	 *  
	 * Circumstance 2 - called when it is important to have the best possible information about
	 * each module - as for example when called from jdmpview. In this case the collected libraries 
	 * may or may not be appended to the core file but if they are then the section header information 
	 * is always better when taken from the collected library so the modules should be constructed 
	 * from the them. 
	 * 
	 * The reason it is important to keep an eye on both circumstances is that they affect one another.
	 * In circumstance 1, some of the constructed modules are of poor quality because the original library is not
	 * available. In circumstance 2, whether or not the library will be found appended to the core file
	 * depends on whether it was found and returned in circumstance 1. 
	 * 
	 * TODO refactor so that the code paths for the two circumstances are not so entwined. Separate out the 
	 * two functions of gathering the list of names of which libraries exist, needed for both circumstances, and constructing
	 * the best possible image of each library, using core and collected library, only needed for the second circumstance. 
	 * 
	 * There are three sorts of module, too. 
	 * 1. Those found only via the program header table of the core file. This includes most of the system
	 * libraries e.g. ld-linux.so.2. These only have the library name, no path, because they are found from 
	 * the SOname within the module.
	 * 2. Those found only via the debug data in the executable. This can include several of the j9 libraries.
	 * They are present within the core file but the route to the SOname is broken somehow
	 * 3. Those found both ways - most of the j9 libraries are in this case. However note that the 
	 * names will be different because the names found via the debug data are full pathnames and the 
	 * names found via the SOname is just the library name. However they can be matched up via the load
	 * address which is available on both routes. 
	 * 
	 * There are a some oddities too:
	 * 1. the executable always appears in the core file with a SOname of "lib.so"
	 * 2. The core file always contains a library called linux-gate.so which does not correspond to 
	 * a file on disk
	 * 3. Sometimes the same file - e.g. libvmi.so, and the executable itself - will be mapped into memory 
	 * twice or more at different addresses so the same name will appear more than once in the 
	 * list from the core file.
	 */
private void readModules() throws IOException {
    if (_executable == null || _executable instanceof MissingFileModule) {
        _modulesException = null;
        _modules = new LinkedList<IModule>();
        readProcessData();
        // Try to find the executable image either on disk or appended to the core file by library collection.
        // If we can we will probably also find the libraries on disk or appended to the core file and will
        // therefore get good section header tables.
        // Otherwise use the copy of the executable within the core file. It may contain some of the library info
        // so it makes a good fallback.
        LibraryDataSource executableFile = findExecutableOnDiskOrAppended();
        ELFFileReader executableELF = null;
        if (executableFile != null && executableFile.getType() != LibraryDataSource.Source.NOT_FOUND && !useLoadedLibraries) {
            try {
                executableELF = getELFReaderFromDataSource(executableFile);
            } catch (InvalidDumpFormatException e) {
            // Not an ELF file.
            }
            if (null != executableELF) {
                createAllModules(executableELF, executableFile.getName());
            }
        } else if (_executable instanceof MissingFileModule) {
            logger.log(Level.FINE, "Libraries unavailable, falling back to loaded modules within the core file.");
            executableELF = getELFReaderForExecutableWithinCoreFile();
            if (null != executableELF) {
                createAllModules(executableELF, _executablePathOverride);
            } else {
                _executable = new MissingFileModule(_process, _executableFileName, Collections.<IMemoryRange>emptyList());
            }
        } else {
            _executable = new MissingFileModule(_process, _executableFileName, Collections.<IMemoryRange>emptyList());
        }
    }
}

Example 2 with LibraryDataSource

use of com.ibm.j9ddr.corereaders.LibraryDataSource in project openj9 by eclipse.

the class AIXDumpReader method loadModule.

private void loadModule(ILibraryResolver resolver, IProcess proc, long textVirtualAddress, long textSize, long dataVirtualAddress, long dataSize, String fileName, String objectName, String moduleName, boolean loadingExecutable) {
    // .data range will be loaded in core. .text range will be in the module itself.
    IMemoryRange data = new MemoryRange(proc.getAddressSpace(), dataVirtualAddress, dataSize, ".data");
    IModule module;
    IMemorySource text;
    try {
        LibraryDataSource library = null;
        if (loadingExecutable) {
            library = resolver.getLibrary(fileName, true);
        } else {
            library = resolver.getLibrary(fileName);
        }
        IModuleFile moduleFile = loadModuleFile(library, objectName);
        text = moduleFile.getTextSegment(textVirtualAddress, textSize);
        List<? extends ISymbol> symbols = moduleFile.getSymbols(textVirtualAddress);
        List<IMemoryRange> moduleMemoryRanges = new LinkedList<IMemoryRange>();
        moduleMemoryRanges.add(text);
        moduleMemoryRanges.add(data);
        module = new Module(proc, moduleName, symbols, moduleMemoryRanges, textVirtualAddress, moduleFile.getProperties());
    } catch (Exception e) {
        // Create a non-backed memory range for the text segment (so we know it exists)
        text = new UnbackedMemorySource(textVirtualAddress, textSize, "Native library " + moduleName + " couldn't be found", 0, ".text");
        List<IMemoryRange> moduleMemoryRanges = new LinkedList<IMemoryRange>();
        moduleMemoryRanges.add(text);
        moduleMemoryRanges.add(data);
        // Can't find the library - put a stub in with the information we have.
        module = new MissingFileModule(proc, moduleName, moduleMemoryRanges);
    }
    // Add .text to _memoryRanges so it becomes part of the native address space.
    addMemorySource(text);
    if (loadingExecutable) {
        _executable = module;
        _executableTextSection = text;
    } else {
        _modules.add(module);
    }
}

Example 3 with LibraryDataSource

use of com.ibm.j9ddr.corereaders.LibraryDataSource in project openj9 by eclipse.

the class CoreFileResolver method getLibrary.

public LibraryDataSource getLibrary(String fileName, boolean silent) throws FileNotFoundException {
    if (!validFile) {
        throw new FileNotFoundException("Cannot find " + fileName + " as the required libraries are missing from the core file");
    }
    FooterLibraryEntry entry = footer.findEntry(fileName);
    if (entry == null) {
        if (!silent) {
            logger.fine(String.format("Cannot find %s", fileName));
        }
        throw new FileNotFoundException("Cannot find " + fileName);
    }
    LibraryDataSource source;
    try {
        SlidingImageInputStream in = new SlidingImageInputStream(stream, entry.getStart(), entry.getSize());
        source = new LibraryDataSource(fileName, in);
    } catch (IOException e) {
        logger.log(WARNING, "Error setting sliding input window", e);
        source = new LibraryDataSource(fileName);
    }
    return source;
}