search for: et_dyn

The generic-abi thread has gone into broader subjects of the benefits and desireability of the work. I'm willing to take it as given that the encoded size of pure-relative address relocs (i.e. R_*_RELATIVE equivalents)--ultimately the RODATA segment size of a given ET_DYN file--as sole metric is a worthy goal and the ballpark savings ratios we're seeing are worth committing to a new ABI. But I am circumspect about choosing an encoding we will be supporting for decades to come. Whatever we do now will surely be good enough that nobody will want to innovate agai...

...ie. Is there any way to let LLD output executable type obj with -pie option? I'm OK if I have to link twice, first output DYN and then covert to EXEC in some way. Could you give some link command examples on it? lld\ELF\Writer.cpp static uint16_t getELFType() { if (Config->Pic) return ET_DYN; if (Config->Relocatable) return ET_REL; return ET_EXEC; } Thanks Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190123/3d35f540/attachment.html>

On Thu, Dec 14, 2017 at 12:11 AM, Cary Coutant <ccoutant at gmail.com> wrote: >> While adding a 'stride' field is definitely an improvement over simple >> delta+count encoding, it doesn't compare well against the bitmap based >> encoding. >> >> I took a look inside the encoding for the Vim binary. There are some instances >> in the bitmap based

I'm running into a completely different problem. When I do: opt -load LowerFastInvoke.o -help I get the message: Error opening 'LowerFastInvoke.o': LowerFastInvoke.o: only ET_DYN and ET_EXEC can be loaded? Am I missing something?

...Jul 20, 2009 at 6:37 AM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > I'm running into a completely different problem.  When I do: > > opt -load LowerFastInvoke.o -help > > I get the message: > > Error opening 'LowerFastInvoke.o': LowerFastInvoke.o: only ET_DYN and > ET_EXEC can be loaded? > > Am I missing something? Assuming the extension is right, you're trying to load an object file, which isn't allowed; you have to link it first. -Eli

...neth Uildriks<kennethuil at gmail.com> wrote: >> I'm running into a completely different problem.  When I do: >> >> opt -load LowerFastInvoke.o -help >> >> I get the message: >> >> Error opening 'LowerFastInvoke.o': LowerFastInvoke.o: only ET_DYN and >> ET_EXEC can be loaded? >> >> Am I missing something? > > Assuming the extension is right, you're trying to load an object file, > which isn't allowed; you have to link it first. > > -Eli > > _______________________________________________ > L...

...ted does not matter. With a different encoding scheme, future linkers might reorder the relocations or data objects themselves, either to reduce relocation encoding size, or to make relocations more efficient (perhaps to support vectorization). Unfortunately, the numbers which can be derived from ET_DYN files will not reflect to what extent such reordering is possible.

Thanks Bill! But it does not work. I get the error given below when I try to load LLVMExecutionEngine.o in the opt command. Error opening '../../../build/Release/lib/LLVMExecutionEngine.o': ../../../build/Release/lib/LLVMExecutionEngine.o: only ET_DYN and ET_EXEC can be loaded -load request ignored. Any ideas?? Please help me out here. Thanks, Bhavani --- On Sun, 10/26/08, Bill Wendling <isanbard at gmail.com> wrote: > From: Bill Wendling <isanbard at gmail.com> > Subject: Re: [LLVMdev] Error while creating ExecutionEngin...

I am adding -D k=v to yaml2obj, similar to clang -D. This makes it easy to generate {32-bit,64-bit} x {big-endian,little-endian} tests. --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2[[ENCODE]] Type: ET_DYN Machine: EM_X86_64 # RUN: yaml2obj -D BITS=32 -D ENCODE=LSB %s -o %t.32le # RUN: yaml2obj -D BITS=32 -D ENCODE=MSB %s -o %t.32le # RUN: yaml2obj -D BITS=64 -D ENCODE=LSB %s -o %t.64le # RUN: yaml2obj -D BITS=64 -D ENCODE=MSB %s -o %t.64be See https://reviews.llvm.org/D73828 for examples how...

..._MAX () {4096;} sub SZ_ELF32HDR () {52;} sub SZ_ELF64HDR () {64;} # Elf32_Ehdr->e_ident[4]: are variables 32 or 64 bit sub ELFCLASS32 () {1;} sub ELFCLASS64 () {2;} # Elf32_Ehdr->e_type: whether it's an executable, core, object # file or something else entirely. sub ET_EXEC () {2;} sub ET_DYN () {3;} # # ELF Private header # sub SZ_ELF32PHDR {32;} sub SZ_ELF64PHDR {56;} # Elf32_Phdr->p_type. sub PT_INTERP () {3;} # Program interpreter sub readStruct ($$$$$) { my ($fh, $off, $size, $pattern, $fieldNames) = @_; my @values; if (! seek ($fh, $off, 0)) { print "bad seek\n...

...google.com<mailto:maskray at google.com>> wrote: I am adding -D k=v to yaml2obj, similar to clang -D. This makes it easy to generate {32-bit,64-bit} x {big-endian,little-endian} tests. --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2[[ENCODE]] Type: ET_DYN Machine: EM_X86_64 # RUN: yaml2obj -D BITS=32 -D ENCODE=LSB %s -o %t.32le # RUN: yaml2obj -D BITS=32 -D ENCODE=MSB %s -o %t.32le # RUN: yaml2obj -D BITS=64 -D ENCODE=LSB %s -o %t.64le # RUN: yaml2obj -D BITS=64 -D ENCODE=MSB %s -o %t.64be See https://reviews.llvm.org/D73828 for examples how...

On Oct 25, 2008, at 9:51 PM, bhavani krishnan wrote: > Hi, > > I am completely new to llvm. I am trying to build an optimization > pass. I need to interpret some instructions in the pass. To begin > with, I used the exact same code as HowtoUseJIT example. It compiles > fine. While executing using opt, I get the following error at the > point where th executionengine

> Question: is there a good/quick/reliable way to figure out whether a > certain gcc compiler will mis-compile? http://llvm.org/docs/GettingStarted.html#brokengcc lists documented problems with different versions of gcc. I use gcc-4.3.2 with ubuntu 8.10 and haven't had any problems > 2. I ran into exactly the problem you pointed out. (Thank you) > The Makefile needs some update

Hello, use command : opt -load ../Release+Asserts/XX.o -XX <packetbuf.bc> /dev/null then I got the error by use the XX.o in the LLVM pass directory: Error opening "../Release+Asserts/XX.o" only ET_DYN and ET_EXEC can be loaded -load request ignored. I got another error by use the XX.o in the LLVM src directory $LLVM_SRC/Release+Asserts/lib/XX.o: Error opening '../../Release+Asserts/lib/XX.so': ../../Release+Asserts/lib/XX.so: undefined symbol: _ZN4llvm18EQTDDataStructures2IDE -load r...

Hi, I am completely new to llvm. I am trying to build an optimization pass. I need to interpret some instructions in the pass. To begin with, I used the exact same code as HowtoUseJIT example. It compiles fine. While executing using opt, I get the following error at the point where th executionengine is created: opt: symbol lookup error: ../../../Release/lib/Try.so: undefined symbol:

...be specified using hexadecimal or decimal (or other bases supported by `StringRef::to_integer()`). (ex. DT_STRSZ, DT_SYMENT, DT_RELAENT, and others) Here's an example to illustrate this design: !ELF FileHeader: Class: ELFCLASS64 Data: ELFDATA2LSB Type: ET_DYN Machine: EM_X86_64 Sections: - Name: .dynsym Type: SHT_DYNSYM Address: 0x1000 - Name: .data Type: SHT_PROGBITS Flags: [ SHF_ALLOC, SHF_WRITE ] - Name: .dynamic Type: SHT_DYNAMIC Entries: - Tag: DT_SONAME Value: libsomething.so - Tag: DT_S...

Thanks, Shu, I guess I haven't updated since my post went out. There are actually 2 problems: 1. mis-compilation: My LLVM-2.5 turned out to be mis-compiled using gcc-4.4.0 (surprise to me) on Debian4-32b. I tried a few different compilers, and gcc-4.0.4 (a relatively old one, again surprised me) seems to work out fine. Question: is there a good/quick/reliable way to figure out whether a

...dr *)page; + = + printk("Remapping vsyscall page to %08x\n", (unsigned int)VDSO_HIGH_BASE); + + /* Sanity checks against insmoding binaries or wrong arch, + weird elf version */ + if (memcmp(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VDSO_HIGH_BASE; + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALL...

...dr *)page; + = + printk("Remapping vsyscall page to %08x\n", (unsigned int)VDSO_HIGH_BASE); + + /* Sanity checks against insmoding binaries or wrong arch, + weird elf version */ + if (memcmp(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VDSO_HIGH_BASE; + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALL...

2012/1/23 Bendersky, Eli <eli.bendersky at intel.com>: > Hi, > > I would like to examine the implications you mention in more detail. > Thank you! > (1) Symbol address > According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, > st_value is an offset from the