search for: e_machine

.../lists.fedorahosted.org/archives/list/elfutils-devel at lists.fedorahosted.org/message/OEOF26ZHEJLHPOMRMOGDXTMYXUHPWVGA/ > > I haven't sent one yet for binutils. > >>> + EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine Great, can that be assumed the final magic e_machine number for the ELF header that eBPF loaders can check for as well then (I do like 0xeb9f ;))? >> was this id reserved this with whoever managing the numbers ? >> The only reason bpf backend used em_none is that we were couldn't >> figure out who's responsible for keeping...

Hi vedant, 1. The definition is from llvm/Supprot/ELF.h. But this machine information(e_machine) is given to compiler at lib/MC/ELFObjectWriter.cpp. I greped the whole llvm project and found that e_machine was assigned at only two files. One was lib/MC/ELFObjectWriter.cpp(there was an comment said “e_machine=target”) and the other was tools/obj2yaml/elf2yaml.cpp(GDB stopped only at the former...

...e is provided by biutils. I think these ELF header information is provided by my binutils now, so maybe I have to modify binutils code to provide ELF header to llvm? Second, I’m sorry to say that I’m now working on llvm-4.0.0 and in ELF.cpp there is no “return getDynamicTagAsString(getHeader()->e_machine, Type);”. But I think it makes sense ELF file reader get nothing because my compiler doesn’t write these information. It seems I have to find somewhere(maybe an ELF file writer) to write e_machine so my reader will read this. But I have no idea where to write it now. 2. In CoverageMapping....

...ot; loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by " EF.getHeader()->e_machine" but I found "e_machine" is defined somewhere in MCAssembler(My compiler uses binutils as assembler) . Although I make some hacks to pass this checking, I still get other errors. So my problem is whether llvm-cov has to work with MCAssembler and is it possible to do it with binutils?...

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > This same value for EM_BPF is being propagated to glibc, > elfutils, and binutils. great! Can you share the link to glibc and the other patches? > diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.h > index 352fd8a..fb8ff71 100644 > ---

Hello, I’m working on porting llvm to build for 65816, and I wanted to use a value of e_machine for this. I was wondering if there is a process for getting a value reserved. I’ve seen some information but its from many years ago, and seems to be well out of date? Just wanted to ask people who would likely know. -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

...d to 64bit/32bit. Anyway, we can parse out the >>>> AT_name now, DW_AT_LOCATION still missed and need your help. >>> Another thing about DW_AT_name, we've already found that the name string is stored indirectly and needs relocation which is architecture specific, while the e_machine info in bpf obj file is "unknown", both objdump and libdw cannot parse DW_AT_name correctly. Should we just use a known architeture for bpf object file instead of "unknown"? If so, we can use the existing relocation codes in libdw and get DIE name by simply invoking dwarf_diena...

This patch allows core-dumping to work on a cross-bit host/guest configuration, whereas previously that was not supported. It supports both PV and FV guests. The core file format generated by the host, needs to match that of the guest, so an alignment issue is addressed, along with the p2m frame list handling being done according to the guest size. Signed-off-by: Bruce Rogers

This is a new version of the unified lguest launcher that applies to the current tree. According to rusty's suggestion, I'm bothering less to be able to load 32 bit kernels on 64-bit machines: changing the launcher for such case would be the easy part! In the absence of further objections, I'll commit it. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> -- =

This is a new version of the unified lguest launcher that applies to the current tree. According to rusty's suggestion, I'm bothering less to be able to load 32 bit kernels on 64-bit machines: changing the launcher for such case would be the easy part! In the absence of further objections, I'll commit it. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> -- =

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where ArchType would be passed to ELFObjectWriter and decoded into the correct 16-bit value. The...

Hi all, I'm trying to support llvm-cov for a new architecture and I have successfully built compiler-rt for my arch. Following steps shown in https://clang.llvm.org/docs/SourceBasedCodeCoverage.html , I encountered an error for the last step(step of llvm-cov show). The command line was (supposed my arch is XXXX) "llvm-cov show -arch=XXXX ./foo -instr-profile=foo.profdata" and the

...n instance of a subclass of MCELFObjectTargetWriter is created. I looked at the approach taken by both Mips and X86 for implementing ILP32 and neither seems applicable. For x86 x32, there is the combination of IsELF64 == false and OSABI == EM_X86_64, but that doesn't seem applicable, as the ELF e_machine field is the same for the existing and the new ABI. For Mips N32, code and state in MCELFObjectTargetWriter seems to take care of mapping the relocation values and the ELF e_flags bit EF_MIPS_ABI_ON32 is set. I'm trying to implement the AArch64 ILP32 ELF ABI.Ideally, I'd like to be able to...

...e_phnum || eh->e_phoff + eh->e_phentsize * eh->e_phnum > len) eh = NULL; /* No valid ELF header found */ + /* Determine 64-bit images */ + if ((eh != NULL) || + len < sizeof(Elf64_Ehdr) || + memcmp(eh64->e_ident, "\x7f" "ELF\2\1\1", 6) || + (eh64->e_machine != EM_X86_64) || + eh64->e_version != EV_CURRENT || + eh64->e_ehsize < sizeof(Elf64_Ehdr) || eh64->e_ehsize >= len || + eh64->e_phentsize < sizeof(Elf64_Phdr) || + !eh64->e_phnum || eh64->e_phoff + eh64->e_phentsize * eh64->e_phnum > len) + eh64 = NULL; /* No va...

...- /* Now look for an ELF32 header */ ehdr = (Elf32_Ehdr *)load_addr; - if (*(unsigned long *)ehdr != 0x464c457f - || ehdr->e_ident[EI_DATA] != ELFDATA2LSB - || ehdr->e_ident[EI_CLASS] != ELFCLASS32 - || ehdr->e_machine != EM_386) - { - printf("Fatal: kernel has neither ELF32/x86 nor multiboot load" - " headers.\n"); - exit(1); - } if (ehdr->e_phoff + ehdr->e_phnum*sizeof (*phdr) > load_size) {...

...instance of a subclass of MCELFObjectTargetWriter is created. I looked at the approach taken by both Mips and X86 for implementing ILP32 and neither seems applicable. For x86 x32, there is the combination of IsELF64 == false and OSABI == EM_X86_64, but that doesn't seem applicable, as the ELF e_machine field is the same for the existing and the new ABI. For Mips N32, code and state in MCELFObjectTargetWriter seems to take care of mapping the relocation values and the ELF e_flags bit EF_MIPS_ABI_ON32 is set. I'm trying to implement the AArch64 ILP32 ELF ABI.Ideally, I'd like to be able t...

...-flto=thin) and, in addition to specifying `-target arm-none-eabi`, I specify an architecture specific flag (such as -march=armv7e-m, -mcpu=cortex-m4, or -mthumb, or instead I use -target armv7em-none-eabi), then while calling lld to link I get an error like: ld.lld: error: main.o: could not infer e_machine from bitcode target triple thumbv7em-none--eabi LLD 4.0.0 I am working on Linux and these two problems seem to exist on both 4.0rc2 and the current head. I am really happy with the progress LLVM has made, with the upcoming 4.0 release, I have managed to compile and link programs for my embedded p...

...uld not mmap JIT marker\n"; > + return false; > + } > + return true; > +} > + > +bool PerfJITEventListener::FillMachine(LLVMPerfJitHeader &hdr) { > + ssize_t sret; > + char id[16]; > + int fd; > + struct { > + uint16_t e_type; > + uint16_t e_machine; > + } info; > + > + fd = ::open("/proc/self/exe", O_RDONLY); > + if (fd == -1) { > + errs() << "could not open /proc/self/exe\n"; > + return false; > + } > + > + sret = ::read(fd, id, sizeof(id)); > + if (sret != sizeof(id)) { &gt...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that