search for: plts

...ll work on x86-64 is to use the address of a routine's PLT as its "address" in all cases. By putting the PLT in 32-bit address space, some ancient BASIC or Fortran program can continue to use an INTEGER*4 to hold a routine's "address" and pass it around. Of course, our PLTs won't be actual dynamic loading code but just trampolines to the 64-bit code. The PLTs provide a consistent "address of routine" for pointer comparisons, etc just like the "primary function descriptor" on Itanium. John

> On Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a target-specific plan in mind. >> >> If you go with your “unnamedfunc” approach, you’ll have to define the semantics of what that means, and it will need to mean something on ta...

...code. It was even in our internal project management bullet list and assigned to me by my request. As I learned as I implemented more and more of lld, the actual application of relocations is small part of the linker interaction. A big part is deciding about relaxations, copy relocations, gots and plts, so I rewrote the relocation handling in its current form (r266158). That involves saving information during the first of two passes over the relocations. I really don't think that that is what the JIT wants. > Now maybe the JIT's linking functionality should be so different from > w...

...Checking the code for rtld, it explicitly asks for memory at a specific address and keeps track of the regions it has used. >>> >>> >>> I was under the impression that, in the small memory model, each .so >>> had to be small, but because of the use of GOTs and PLTs they could be >>> anywhere in memory. If we allocate the tls memory in the same >>> allocator call that allocates space for the text section this would >>> work, no? >> >> I'm not sure what you mean by 'we' in this context. The memory for TLS (in...

..., the @plt modifier on x86/aarch64 (func at plt), a thunk, or anything that’s equivalent to the resolved function at runtime. Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a target-specific plan in mind. If you go with your “unnamedfunc” approach, you’ll have to define the semantics of what that means, and it will need to mean something on targets without a PL...

...gt;> On Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> >> Sorry for the delay responding Leonard. I don’t really understand your >> rationale here. A PLT entry is a completely target specific concept >> because some targets don’t have PLTs. I don’t think there is any reason >> that a frontend would abstractly generate this unless they already have a >> target-specific plan in mind. >> >> If you go with your “unnamedfunc” approach, you’ll have to define the >> semantics of what that means, and it will ne...

...'t expect that there are many > things that we can share between JIT linkers and static linkers. Of > course there may be something that I don't know well about JIT, but > that's my feeling at this moment. Right now, both parts of LLVM have code to process relocations, produces PLTs, etc. Those are target-specific things and it would be nice not to have to code them twice. Obviously, I could be oversimplifying the situation. -Hal > > -Hal > > > > > > > > Also, please consider what is so bad about writing a file. If > > > your >...

On 15 May 2013, at 01:17, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > I believe that assertion indicates that something didn't get loaded into the lower 2GB of address space. That is, the memory manager isn't allocating memory in that range. > > I'm sure there must be a way to allocate memory in that range on FreeBSD. The system loader has to do

Hi David, I believe that assertion indicates that something didn't get loaded into the lower 2GB of address space. That is, the memory manager isn't allocating memory in that range. I'm sure there must be a way to allocate memory in that range on FreeBSD. The system loader has to do it, right? I just don't know what makes it happen. -Andy -----Original Message----- From: Dr

----- Original Message ----- > From: "Rafael Avila de Espindola" <rafael.espindola at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 2:13:49 PM > Subject: Re: [llvm-dev] LLD status update and

...+ * custom one for this module. + */ + if (!duplicate_rel(rela, i) && + !find_got_kernel_entry(s, rela + i)) + ret++; + break; + } + } + return ret; +} + +/* + * Generate GOT entries for GOTPCREL relocations that do not exists in the + * kernel GOT. Based on arm64 module-plts implementation. + */ +int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, + char *secstrings, struct module *mod) +{ + unsigned long gots = 0; + Elf_Shdr *symtab = NULL; + Elf64_Sym *syms = NULL; + char *strings, *name; + int i; + + /* + * Find the empty .got section so we can...

On Tue, Dec 13, 2016 at 12:40 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Andrew Kelley" <superjoe30 at gmail.com>, "Rui Ueyama" < > ruiu at google.com> > > Cc: "llvm-dev" <llvm-dev at

...Finkel <hfinkel at anl.gov> wrote: >>>> >>>> >>>> Sorry for the delay responding Leonard. I don’t really understand your >>>> rationale here. A PLT entry is a completely target specific concept >>>> because some targets don’t have PLTs. I don’t think there is any reason >>>> that a frontend would abstractly generate this unless they already have a >>>> target-specific plan in mind. >>>> >>>> If you go with your “unnamedfunc” approach, you’ll have to define the >>>> sema...

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

...opped from the top of stack and looked up. This second attempted lookup must     succeed, in which case processing continues normally. A failure is a fatal error. This concept of a “default null frame group” is especially convenient for dealing with disconnected code sequences such as trampolines, PLTs, and the like. The extended RBP-based and RSP-based frame modes (MODEs = 9 and 10) are simple supersets of their more traditional predecessors. The large RSP-based frame mode (MODE = 11) is also a superset of mode 3 except that instead of finding the stack size in the instruction stream, it is fo...

...ked up. This second > attempted lookup must > succeed, in which case processing continues normally. A failure is a > fatal error. > > This concept of a “default null frame group” is especially convenient > for dealing with > disconnected code sequences such as trampolines, PLTs, and the like. > > The extended RBP-based and RSP-based frame modes (MODEs = 9 and 10) are > simple > supersets of their more traditional predecessors. > > The large RSP-based frame mode (MODE = 11) is also a superset of mode 3 > except that instead > of finding the stack...

...mpted lookup must > > succeed, in which case processing continues normally. A failure is a > > fatal error. > > > > This concept of a “default null frame group” is especially convenient > > for dealing with > > disconnected code sequences such as trampolines, PLTs, and the like. > > > > The extended RBP-based and RSP-based frame modes (MODEs = 9 and 10) are > > simple > > supersets of their more traditional predecessors. > > > > The large RSP-based frame mode (MODE = 11) is also a superset of mode 3 > > except that i...

On Thu, Sep 26, 2019 at 5:13 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Thursday, September 26, 2019 3:24 PM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at

...oked up. This second > attempted lookup must > succeed, in which case processing continues normally. A failure is a > fatal error. > > This concept of a “default null frame group” is especially convenient > for dealing with > disconnected code sequences such as trampolines, PLTs, and the like. > > The extended RBP-based and RSP-based frame modes (MODEs = 9 and 10) are > simple > supersets of their more traditional predecessors. > > The large RSP-based frame mode (MODE = 11) is also a superset of mode 3 > except that instead > of finding the stack...

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