search for: elf_rel

Hi Shankar, I almost implement ELFRelocationReader but still not completely sure that this is a right direction. Suppose somebody wants to override creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel` record. Let's consider two implementations A and B: A: ===== 1. Factor out `ELFReference` creation from `createDefinedAtomAndAssignRelocations` into a couple of virtual functions with the following signature: ELFReference<ELFT> * createRelocationReference(const Elf_Sym &a...

...l. ReferenceRangeT getReferences(StringRef sectionName, Elf_Sym *symbol, ArrayRef<uint8_t> content); protected: // Target can override these methods in the inherited class. virtual ELFReference<ELFT> *createReference(Elf_Rela &rel, Elf_Sym *symbol); virtual ELFReference<ELFT> *createReference(Elf_Rel &rel, Elf_Sym *symbol); }; On Wed, Feb 26, 2014 at 9:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I was thinking of having a separate class that would return a vector of > ELFR...

...efaultLayout::getPLTRelocationTable(). Call these functions when we need to create relocation tables. By default these function create .rela.* sections. - Override createDynamicRelocationTable() and getPLTRelocationTable() in the MipsTargetLayout to create .rel.* sections. - Add support for writing Elf_Rel entries to the RelocationTable class. Maybe it's better to inherit form RelocationTable two separate classes deal with lf_Rela / Elf_Rel entries. - It's unclear to me how to select names of symbols like __rela_iplt_* / __rel_iplt_* and dynamic table tag DT_RELA / DT_REL. Is it an appropria...

..._references.push_back(ERef); > } What do you mean by removing relocation reading from the ELFObjectFile? I considered to customize the relocation reading for MIPS targets and my first idea was to factor out ELFReference creation into a couple of virtual functions. The first one is for Elf_Rel, the second one is for Elf_Rela. Then I planned to override these functions in the MipsELFFile class. But it looks like you have more profound idea. Could you share it? Thanks. -- Simon

...ationTable(). Call these functions when we > need to create relocation tables. By default these function create > .rela.* sections. > - Override createDynamicRelocationTable() and getPLTRelocationTable() > in the MipsTargetLayout to create .rel.* sections. > - Add support for writing Elf_Rel entries to the RelocationTable > class. Maybe it's better to inherit form RelocationTable two separate > classes deal with lf_Rela / Elf_Rel entries. > - It's unclear to me how to select names of symbols like __rela_iplt_* > / __rel_iplt_* and dynamic table tag DT_RELA / DT_REL....

...nores it. + */ +static int is_in_xenpvh_assembly(ElfW(Addr) offset) +{ + ElfW(Sym) *sym = sym_lookup("pvh_start_xen"); + return sym && (offset >= sym->st_value) && + (offset < (sym->st_value + sym->st_size)); +} static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, const char *symname) @@ -895,8 +905,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, * the relocations are processed. * Make sure that the offset will fit. */ - if (r_type != R_X86_64_64 && (int32_t)offset != (int64_t...

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

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

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - 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

Changes: - 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 dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - 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 dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends