search for: sh_addralign

...mbinfo.syms.e.shndx = eh64->e_shstrndx; + + for (i = 0; i < eh64->e_shnum; i++) { + addr_t align; + + if (!sh64[i].sh_size) + continue; /* Empty section */ + if (sh64[i].sh_flags & SHF_ALLOC) + continue; /* SHF_ALLOC sections should have PHDRs */ + + align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; + addr = map_data((char *)ptr + sh64[i].sh_offset, + sh64[i].sh_size, align, MAP_HIGH); + if (!addr) { + error("Failed to map symbol section\n"); + return NULL; + } + sh64[i].sh_addr = addr; } } } else if (mbh_len && (mbh-...

...flags & MULTIBOOT_AOUT_KLUDGE))) { /* Load 64-bit ELF */ regs.eip = eh64->e_entry; /* Can be overridden further down... */ @@ -378,7 +378,7 @@ struct multiboot_header *map_image(void *ptr, size_t len) continue; /* SHF_ALLOC sections should have PHDRs */ align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; - addr = map_data((char *)ptr + sh64[i].sh_offset, + addr = map_data((char *)ptr + sh64[i].sh_offset, sh64[i].sh_size, align, MAP_HIGH); if (!addr) { error("Failed to map symbol section\n"); -- 2.0.0

Suppose i write // foo.cpp __attribute__((section(“foo”))) int x; // bar.cpp __attribute__((section(“foo”))) int y; And i compile and link these two object files together using lld. What assumptions can I make regarding alignment/padding between the two symbols? I’m comfortable getting an answer by reading the source, but that won’t tell if any properties i discover are guaranteed or just

Hello, all experts. When I use pid provider, my Dscript with -F option output the codepath with flowindent as you know, e.g. -> main -> f1 -> f2 however I realized that the exec file I used at that time was stripped. Does anyone know the reason why I could see the function names? Thanks in advance. -- This message posted from opensolaris.org

...s/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf Put it in the simplest way, a Jcc instruction whose address ≡ 30 or 31 (mod 32) should be avoided. There are assembler level (MC) mitigations (function sections are overaligned to 32), but because we use basic block sections (sh_addralign<32) and need reordering, we have to redo some work at the linking stage. After losing the representation of MCInst, it is not clear to me how we can insert NOPs/segment override prefixes without doing disassembly work in the linker. Route 2 does heavy lifting work in the compiler, which can na...

...continue; + + /* sort by type, symbol index and addend */ + sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL); + + gots += count_gots(syms, rels, numrels); + } + + mod->arch.core.got->sh_type = SHT_NOBITS; + mod->arch.core.got->sh_flags = SHF_ALLOC; + mod->arch.core.got->sh_addralign = L1_CACHE_BYTES; + mod->arch.core.got->sh_size = (gots + 1) * sizeof(u64); + mod->arch.core.got_num_entries = 0; + mod->arch.core.got_max_entries = gots; + + /* + * If a _GLOBAL_OFFSET_TABLE_ symbol exists, make it absolute for + * modules to correctly reference it. Similar to s390 i...

....text 0x0000000000011008 0x18 arm-thumb-undefined-weak.o The *fill* is visible as a nop in the disassembly for the LD produced image. Strictly speaking I think LD is producing a file that doesn't strictly conform to ELF here as the sh_addr of the .text OutputSection is 0 modulo sh_addralign (4). In practice it probably wouldn't make much difference. My preference is for LLD's behaviour here. Peter On 18 September 2017 at 03:28, Leslie Zhai <lesliezhai at llvm.org.cn> wrote: > Hi Peter, > > Map file about LD for ARC target > https://drive.google.com/open?i...

...ned-weak.o >> >> The *fill* is visible as a nop in the disassembly for the LD produced >> image. >> >> Strictly speaking I think LD is producing a file that doesn't strictly >> conform to ELF here as the sh_addr of the .text OutputSection is 0 >> modulo sh_addralign (4). In practice it probably wouldn't make much >> difference. My preference is for LLD's behaviour here. > > > It might be arm-linux-gnu toolchain's issue: > > $ arm-linux-gnu-gcc -o arm-thumb-undefined-weak-ld.o -c > arm-thumb-undefined-weak.s > > arm-thu...

..._type */ #define SHT_NULL 0 @@ -285,7 +294,8 @@ struct elf64_phdr { #define SHN_ABS 0xfff1 #define SHN_COMMON 0xfff2 #define SHN_HIRESERVE 0xffff - + +#ifndef __ASSEMBLY__ struct elf32_shdr { Elf32_Word sh_name; Elf32_Word sh_type; @@ -311,6 +321,7 @@ struct elf64_shdr { Elf64_Xword sh_addralign; /* Section alignment */ Elf64_Xword sh_entsize; /* Entry size if section holds table */ }; +#endif /* __ASSEMBLY__ */ #define EI_MAG0 0 /* e_ident[] indexes */ #define EI_MAG1 1 @@ -344,6 +355,7 @@ struct elf64_shdr { #define ELFOSABI_NONE 0 #define ELFOSABI_LINUX 3 +#define ELFOSAB...

..._type */ #define SHT_NULL 0 @@ -285,7 +294,8 @@ struct elf64_phdr { #define SHN_ABS 0xfff1 #define SHN_COMMON 0xfff2 #define SHN_HIRESERVE 0xffff - + +#ifndef __ASSEMBLY__ struct elf32_shdr { Elf32_Word sh_name; Elf32_Word sh_type; @@ -311,6 +321,7 @@ struct elf64_shdr { Elf64_Xword sh_addralign; /* Section alignment */ Elf64_Xword sh_entsize; /* Entry size if section holds table */ }; +#endif /* __ASSEMBLY__ */ #define EI_MAG0 0 /* e_ident[] indexes */ #define EI_MAG1 1 @@ -344,6 +355,7 @@ struct elf64_shdr { #define ELFOSABI_NONE 0 #define ELFOSABI_LINUX 3 +#define ELFOSAB...

...sh_type */ #define SHT_NULL 0 @@ -285,6 +294,7 @@ typedef struct elf64_phdr { #define SHN_COMMON 0xfff2 #define SHN_HIRESERVE 0xffff +#ifndef __ASSEMBLY__ typedef struct elf32_shdr { Elf32_Word sh_name; Elf32_Word sh_type; @@ -310,6 +320,7 @@ typedef struct elf64_shdr { Elf64_Xword sh_addralign; /* Section alignment */ Elf64_Xword sh_entsize; /* Entry size if section holds table */ } Elf64_Shdr; +#endif /* __ASSEMBLY__ */ #define EI_MAG0 0 /* e_ident[] indexes */ #define EI_MAG1 1 @@ -343,6 +354,7 @@ typedef struct elf64_shdr { #define ELFOSABI_NONE 0 #define ELFOSABI_LINUX...

...sh_type */ #define SHT_NULL 0 @@ -285,6 +294,7 @@ typedef struct elf64_phdr { #define SHN_COMMON 0xfff2 #define SHN_HIRESERVE 0xffff +#ifndef __ASSEMBLY__ typedef struct elf32_shdr { Elf32_Word sh_name; Elf32_Word sh_type; @@ -310,6 +320,7 @@ typedef struct elf64_shdr { Elf64_Xword sh_addralign; /* Section alignment */ Elf64_Xword sh_entsize; /* Entry size if section holds table */ } Elf64_Shdr; +#endif /* __ASSEMBLY__ */ #define EI_MAG0 0 /* e_ident[] indexes */ #define EI_MAG1 1 @@ -343,6 +354,7 @@ typedef struct elf64_shdr { #define ELFOSABI_NONE 0 #define ELFOSABI_LINUX...

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to