com.oracle.objectfile

Interface ObjectFile.RelocatableSectionImpl

All Superinterfaces:

ElementImpl

All Known Subinterfaces:

ObjectFile.ProgbitsSectionImpl

All Known Implementing Classes:

BasicProgbitsSectionImpl, CVSymbolSectionImpl, CVTypeSectionImpl, DwarfAbbrevSectionImpl, DwarfARangesSectionImpl, DwarfFrameSectionImpl, DwarfFrameSectionImplAArch64, DwarfFrameSectionImplX86_64, DwarfInfoSectionImpl, DwarfLineSectionImpl, DwarfLocSectionImpl, DwarfSectionImpl, DwarfStrSectionImpl, ELFNobitsSection, ELFProgbitsSection, ELFUserDefinedSection, MachORegularSection, MachOUserDefinedSection, MachOZeroFillSection, PECoffNobitsSection, PECoffProgbitsSection, PECoffUserDefinedSection, StringSectionImpl

Enclosing class:

ObjectFile

public static interface ObjectFile.RelocatableSectionImpl
extends ElementImpl

Method Summary

Modifier and Type	Method and Description
ObjectFile.Element	getOrCreateRelocationElement(long addend) Force the creation of a relocation section/element for this section, and return it.
void	markRelocationSite(int offset, ByteBuffer bb, ObjectFile.RelocationKind k, String symbolName, long addend) Record (in a format-specific way) that data at the given offset in the file, for the given number of bytes, should be fixed up according to the value of the given symbol and the given kind of relocation.

Methods inherited from interface com.oracle.objectfile.ElementImpl

getAlignment, getDecisions, getDependencies, getElement, getMemSize, getOrDecideContent, getOrDecideOffset, getOrDecideSize, getOrDecideVaddr, isLoadable, isReferenceable, setElement

Method Detail

markRelocationSite

void markRelocationSite(int offset,
                        ByteBuffer bb,
                        ObjectFile.RelocationKind k,
                        String symbolName,
                        long addend)

Record (in a format-specific way) that data at the given offset in the file, for the given number of bytes, should be fixed up according to the value of the given symbol and the given kind of relocation. Depending on the object file format, kind of file, and target architecture, the available kinds of relocation and addend modes all vary considerably. Supporting a uniform interface is therefore complicated. In particular, the implementation of these methods somehow has to tell the caller how to fix up the section content, or fix it up itself. For example, ELF uses explicit addends for dynamic linking on x86-64, but Mach-O in the same case always uses implicit (inline) addends and cannot encode explicit addends. I can see two solutions. Firstly, the Mach-O implementation could come back to the caller saying "here is what you need to add to the current section contents". Or secondly, the section implementation could take care of it somehow, but that assumes it has access to the actual contents s.t. any changes will not later be clobbered. TODO: CHECK whether this is true of our native native image code.

Parameters:

offset - the offset into the section contents of the beginning of the fixed-up bytes

bb - the byte buffer representing the encoded section contents, at least as far as offset + length bytes

k - the kind of fixup to be applied

symbolName - the name of the symbol whose value is used to compute the fixed-up bytes

addend - a full-width addend, or 0 if unneeded

getOrCreateRelocationElement

ObjectFile.Element getOrCreateRelocationElement(long addend)

Force the creation of a relocation section/element for this section, and return it. This is necessary to avoid the on-demand instantiation of relocation sections at write()-time, which leads to unpredictable results (e.g. not appearing in the ELF SHT, if the SHT was written before the section was created).

Parameters:

addend - whether a full-width addend, or 0 if unneeded

Returns:

the element which will hold relocation records (of the argument-specified kind) for this section