gnu_x64.py

ofrak_patch_maker.toolchain.gnu_x64

GNU_X86_64_LINUX_EABI_10_3_0_Toolchain (GNU_10_Toolchain)

name: str property readonly

Returns:

Type	Description
str	name property that matches the value used in toolchain.conf to access paths

segment_alignment: int property readonly

For example, x86 returns 16. This will most often be used when programmatically allocating memory for code/data.

Returns:

Type	Description
int	required alignment factor for the toolchain/ISA

_get_assembler_target(self, processor) private

Red Balloon Security strongly recommends all users provide their specific hardware target for best results.

Parameters:

Name	Type	Description	Default
processor	ArchInfo		required

Returns:

Type	Description
	a default assembler target for the provided processor unless one is provided in self._config.

Exceptions:

Type	Description
PatchMakerException	if no target provided and program attributes do not correspond to a default value.

Source code in ofrak_patch_maker/toolchain/gnu_x64.py

def _get_assembler_target(self, processor: ArchInfo):
    if self._config.assembler_target:
        return self._config.assembler_target
    return "generic64"

ld_generate_bss_section(memory_region_name) staticmethod

We override this for x64 so we can provide SUBALIGN(1) This is required to correctly estimate how much size we need for bss when splitting up data structures into their own individual bss sections. If we were to let the linker align every structure's section to 8 or 16, it would insert empty space that we had not allocated for the bss memory region. gcc/ld do prefer 8 alignment for data if you don't force this, but it is not likely to be hugely faster on recent hardware for most situations (ie not locked instructions across a cache line): https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/ Pre-2011 x64 chips might be slower with these kinds of accesses, but: - We should not bend over backwards for processors we've not evaluated yet. - .bss handling is already difficult enough as is. - The flexibility granted by this feature likely justifies a relatively small performance impact. We should address this as a problem if future users find that performance is noticeably/severely impacted.

Source code in ofrak_patch_maker/toolchain/gnu_x64.py

@staticmethod
def ld_generate_bss_section(
    memory_region_name: str,
) -> str:
    """
    We override this for x64 so we can provide SUBALIGN(1)
    This is required to correctly estimate how much size we need for bss
    when splitting up data structures into their own individual bss sections.
    If we were to let the linker align every structure's section to 8 or 16, it would
    insert empty space that we had not allocated for the bss memory region.
    gcc/ld do prefer 8 alignment for data if you don't force this, but it is not likely to be
    hugely faster on recent hardware for most situations (ie not locked instructions
    across a cache line):
    https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
    Pre-2011 x64 chips might be slower with these kinds of accesses, but:
       - We should not bend over backwards for processors we've not evaluated yet.
       - .bss handling is already difficult enough as is.
       - The flexibility granted by this feature likely justifies a relatively small performance impact.
    We should address this as a problem if future users find that performance is noticeably/severely impacted.
    """
    bss_section_name = ".bss"
    return (
        f"    {bss_section_name} : SUBALIGN(1) {{\n"
        f"        *.o({bss_section_name}, {bss_section_name}.*)\n"
        f"    }} > {memory_region_name}"
    )