search for: r_x86_64_plt32

...bjdump -r skeleton.o skeleton.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000017 R_X86_64_32S .rodata.str1.1+0x000000000000002b 0000000000000020 R_X86_64_32S .rodata.str1.1+0x0000000000000015 0000000000000029 R_X86_64_PLT32 uprintf-0x0000000000000004 [...] The relocation for the external uprintf call is changed from R_X86_64_PC32 to R_X86_64_PLT32. Normally, amd64/x86 kernel modules are relocatable object files (via ld -r). Because of that, D43383 typically has no impact as the FreeBSD loader sees the relocation...

...48 89 7d e8 mov %rdi,-0x18(%rbp) > 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > 13843: 48 89 c7 mov %rax,%rdi > 13846: e8 00 00 00 00 callq 1384b <func()+0x19> > 13847: R_X86_64_PLT32 std::vector<record, > std::allocator<record> >::vector()-0x4 > .... > This seems a bit odd. You have type `record` and instantiate std::vector with `record`. Usually the instantiated template function is in the same compilation unit, and the relocation type is R_X86_64_PC...

.../home/test1/xen-unstable/xen/xen-syms /home/test1/xen-unstable/xen/common/built_in.o: In function `do_domctl'': /home/test1/xen-unstable/xen/common/domctl.c:656: undefined reference to `__stack_chk_fail'' /home/test1/xen-unstable/xen/common/domctl.c:656: relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `__stack_chk_fail'' /home/test1/xen-unstable/xen/common/built_in.o: In function `cmdline_parse'': /home/test1/xen-unstable/xen/common/kernel.c:84: undefined reference to `__stack_chk_fail'' /home/test1/xen-unstable/xen/common/kernel.c:84: relocation...

...%rdi,-0x18(%rbp) > >> 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > >> 13843: 48 89 c7 mov %rax,%rdi > >> 13846: e8 00 00 00 00 callq 1384b <func()+0x19> > >> 13847: R_X86_64_PLT32 std::vector<record, > >> std::allocator<record> >::vector()-0x4 > >> .... > >> > > > > This seems a bit odd. You have type `record` and instantiate std::vector > > with `record`. Usually the instantiated template function is in the same...

...retq >> >> >> The call to foo does not go through the PLT. That's the behavior seen using clang5. But clang10 generates the PLT32 relocation instead, like this: >> >> $ cat b.s >> .globl _start, foo >> _start: >> .byte 0xe8 >> .reloc ., R_X86_64_PLT32, foo - 4 >> .long foo - . >> foo: >> ret >> >> $ as b.s -o b.o >> $ ld.lld-10 -shared -o b.so b.o >> $ objdump -d b.so >> >> b.so: file format elf64-x86-64 >> >> Disassembly of section .text: >> >> 000000000000...

...rc/xen/.xen-syms.0 /home/user/ether/xen-3.1.0-src/xen/arch/x86/built_in.o: In function `do_invalid_op'': /home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: undefined reference to `memcmp'' /home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:631: relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `memcmp'' /home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: undefined reference to `memcmp'' /home/user/ether/xen-3.1.0-src/xen/arch/x86/traps.c:648: relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `memcmp'' /home/user/...

...ode model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL type relocation entries in my firmware image, which not happen in the clang LTO build. I wish I could enforce the clang normal build not to use the R_X86_64_GOTPCREL relocation type but to use R_X86_64_PC32 or R_X86_64_PLT32 instead. How could I do it? Does it reproduce with clang trunk? Cheers, Rafael

...;> 1383f: 48 8b 45 e8 mov -0x18(%rbp),%rax > >> >> 13843: 48 89 c7 mov %rax,%rdi > >> >> 13846: e8 00 00 00 00 callq 1384b <func()+0x19> > >> >> 13847: R_X86_64_PLT32 std::vector<record, > >> >> std::allocator<record> >::vector()-0x4 > >> >> .... > >> >> > >> > > >> > This seems a bit odd. You have type `record` and instantiate > >> std::vector > >> > with...

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> 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

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> 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

...t lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > A @plt modifer (x86-32, x86-64 and aarch64) in assembly refers to a > function whose address can be insignificant. The assembler produces an > R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be > resolved by the linker to either: > > * the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z ifunc- > noplt is specified))) > * a PLT entry (other cases) > > The address can be insignificant: ultimately the program will...

Compilers don't know about functions that are not defined in the same compilation unit, so they leave call instruction operands as zero (because they can't compute any absolute nor relative address of the destinations), and let linkers fix the address by binary patching. So, what you are seeing is likely a bug of LLD that it fails to fix the address for some reason. Can you dump that

Hi, Mark > #pragma GCC visibility push(hidden) In theory - yes. > If so, what are the options I need to set when configuring llvm and > llvm-gcc? Well... No extra options are needed. > I'm able to compile the module with llvm-gcc (with the above pragma > included), but the kernel still rejects the module at load time saying the > module is compiled with PLT/GOT. Visibility

...e JIT'd code runs. The JIT'd code just needs to refer to it. OK. Are we generating generic dynamic code to do so? It will look like .byte 0x66 leaq x at tlsgd(%rip),%rdi ; R_X86_64_TLSGD to symbol x (MCJIT has to create a GOT entry) .word 0x6666 rex64 call __tls get_addr at plt ; R_X86_64_PLT32 to __tls_get_addr (MCJIT has to create a GOT and a PLT entry) This should work from any place in memory. I wouldn't be surprised if these relocations are not implemented yet, but that should be all that is needed to get tls working. Cheers, Rafael

OK, I get it. Adding "-pie" link option can force 64bits relocation address (e.g. EM_X86_64), instead of the 32bits one (e.g. R_X86_64_32S). I only used -fpic and -fpie in clang LTO compile option, and forgot add the "-pie" link option in ld. So my clang + ld LTO executable was still not position independent. Thank you all! Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86

Gurus- Do llvm/llvm-gcc support pragma definitions for visibility like: #pragma GCC visibility push(hidden) If so, what are the options I need to set when configuring llvm and llvm-gcc? I'm able to compile the module with llvm-gcc (with the above pragma included), but the kernel still rejects the module at load time saying the module is compiled with PLT/GOT. Any Inputs, Insights? Thanks

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Why the private message? If unintentional, please forward this to the list. Ooops, forgot to hit reply-all. Didn't the LLVM lists used to default to reply-to-list behaviour? > So, the JIT is analogous to dlopen, so it should be using general > dynamic and local dynamic models. It is only the

On 31 May 2016 at 01:08, Shi, Steven <steven.shi at intel.com> wrote: > Hi Mehdi, > What's the default code model for x86_64 Mac OS X App? Andrew showed me some example code of Mac OS X App as below, which looks to use the small code model but can run at >4GB high address. Small, but PIC. > For example if you read a global like this the compiler will generate this code.

...tion down to the linker. The only possible use right now seems to be what we used to do for weakref. Given @bar = hidden alias void ()* @foo declare void @foo() define void @zed() { call void @foo() call void @bar() ret void } llc with the pic relocation model will produce a R_X86_64_PLT32 and a R_X86_64_PC32, both pointing to foo. That is, the alias acts as an alternative declaration. The supported way of doing this is to have a proper declaration in the file using the symbol: declare hidden void @bar() declare void @foo() define void @zed() { call void @foo() call v...

...p; @@ -190,16 +358,20 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, if ((s64)val != *(s32 *)loc) goto overflow; break; +#ifdef CONFIG_X86_PIE + case R_X86_64_GOTPCREL: + val = module_emit_got_entry(me, loc, rel + i, sym); + /* fallthrough */ +#endif case R_X86_64_PC32: case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; *(u32 *)loc = val; -#if 0 - if ((s64)val != *(s32 *)loc) + if (IS_ENABLED(CONFIG_X86_PIE) && + (s64)val != *(s32 *)loc) goto overflow; -#endif break; default: pr_err("%s: Unknown...