search for: sht_rela

...lowing loop: for (InputSectionBase *Sec : InputSections) {     if (Sec->Flags & SHF_LINK_ORDER)         Sec->Live = Sec->getLinkOrderDep()->Live;     else {         bool IsAlloc = (Sec->Flags & SHF_ALLOC);         bool IsRel = (Sec->Type == SHT_REL || Sec->Type == SHT_RELA);         if (!IsAlloc && !IsRel)         Sec->Live = true;     } } If an input section has the SHF_LINK_ORDER flag set, it propagates the liveness of this section to the parent. This allows the garbage collector to also remove children sections if dependent parent sections are mar...

...nputSectionBase *Sec : InputSections) { > if (Sec->Flags & SHF_LINK_ORDER) > Sec->Live = Sec->getLinkOrderDep()->Live; > else { > bool IsAlloc = (Sec->Flags & SHF_ALLOC); > bool IsRel = (Sec->Type == SHT_REL || Sec->Type == SHT_RELA); > if (!IsAlloc && !IsRel) > Sec->Live = true; > } >} > >If an input section has the SHF_LINK_ORDER flag set, it propagates the >liveness >of this section to the parent. This allows the garbage collector to also >remove >children section...

...ms) { + pr_err("%s: module symtab section missing\n", mod->name); + return -ENOEXEC; + } + + for (i = 0; i < ehdr->e_shnum; i++) { + Elf64_Rela *rels = (void *)ehdr + sechdrs[i].sh_offset; + int numrels = sechdrs[i].sh_size / sizeof(Elf64_Rela); + + if (sechdrs[i].sh_type != SHT_RELA) + 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...

...that your linker keeps the “compact unwind group description” records as is and just concatenates them, and the runtime would need to understand the prolog/epilog encoding. I would think that just widening the group record (as you suggest in 5.1) would be much simpler (like SHT_REL was widened to SHT_RELA). -Nick > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is our proposal to extend/enhance the x86-64 compact unwind > descriptors to fully describe the prologue/epilogue for asynchronous > unwinding. I believe there are...

...eps the “compact > unwind group description” records as is and just concatenates them, and the > runtime would need to understand the prolog/epilog encoding. I would think > that just widening the group record (as you suggest in 5.1) would be much > simpler (like SHT_REL was widened to SHT_RELA). > > -Nick > > > > > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Here is our proposal to extend/enhance the x86-64 compact unwind > > descriptors to fully describe the prologue/epilogue for asy...

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to

"On Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul

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