search for: em_x86_64

Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info

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 -D simplifies tests. Do...

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

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.

...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 -D simplifies tests. Do...

...ine and the setting of ABIname in MCTargetOptions to where an 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 th...

Hi, I was wondering if there is any documentation on how to write a bare metal application for Xen. I don''t need to parse the device tree and such yet, a simple booting "Hello World" would be fine :-) We wrote one and when trying to boot we get ( this was an uncompressed binary, no image): libxl: notice: libxl_numa.c:451:libxl__get_numa_candidate: NUMA placement failed,

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 021...

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> -- =

...->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 valid ELF64 hea...

...imal 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_SYMTAB Value: .dynsym...

...e and the setting of ABIname in MCTargetOptions to where an 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...

...org/ml/binutils/2006-05/msg00466.html --- a/binutils/bfd/elf64-x86-64.c +++ b/binutils/bfd/elf64-x86-64.c @@ -3630,7 +3630,8 @@ static const struct bfd_elf_special_section #define TARGET_LITTLE_NAME "elf64-x86-64" #define ELF_ARCH bfd_arch_i386 #define ELF_MACHINE_CODE EM_X86_64 -#define ELF_MAXPAGESIZE 0x100000 +#define ELF_MAXPAGESIZE 0x200000 +#define ELF_MINPAGESIZE 0x1000 #define elf_backend_can_gc_sections 1 #define elf_backend_can_refcount 1 When building klibc with new binutils, I get: $ readelf -l usr/klibc/libc.so...

...age_offset) +{ +#ifdef CONFIG_X86_64 + void *addr; + Elf64_Phdr phdr[ehdr->e_phnum]; + unsigned int i; + Elf64_Shdr sec[ehdr->e_shnum]; + Elf64_Sym *syms; + char *strtab = NULL; + unsigned long nsyms = 0; + + /* Sanity checks. */ + if (ehdr->e_type != ET_EXEC + || ehdr->e_machine != EM_X86_64 + || ehdr->e_phentsize != sizeof(Elf64_Phdr) + || ehdr->e_phnum < 1 || ehdr->e_phnum > 65536U/sizeof(Elf64_Phdr)) + errx(1, "Malformed elf64 header"); + + if (lseek(elf_fd, ehdr->e_phoff, SEEK_SET) < 0) + err(1, "Seeking to program headers"); + if...

...age_offset) +{ +#ifdef CONFIG_X86_64 + void *addr; + Elf64_Phdr phdr[ehdr->e_phnum]; + unsigned int i; + Elf64_Shdr sec[ehdr->e_shnum]; + Elf64_Sym *syms; + char *strtab = NULL; + unsigned long nsyms = 0; + + /* Sanity checks. */ + if (ehdr->e_type != ET_EXEC + || ehdr->e_machine != EM_X86_64 + || ehdr->e_phentsize != sizeof(Elf64_Phdr) + || ehdr->e_phnum < 1 || ehdr->e_phnum > 65536U/sizeof(Elf64_Phdr)) + errx(1, "Malformed elf64 header"); + + if (lseek(elf_fd, ehdr->e_phoff, SEEK_SET) < 0) + err(1, "Seeking to program headers"); + if...

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

Hi, --- background ---------------------------------------------------- * what the makedumpfile is: To shorten the size of the dumpfile and the time of creating the dumpfile, makedumpfile copies only the necessary pages for analysis to the dumpfile from /proc/vmcore. You can specify the kind of unnecessary pages with dump_level. If you want to shorten the size further, enable the

The following dump-core patches changes its format into ELF, adds PFN-GMFN table, HVM support, and adds experimental IA64 support. - ELF format Program header and note section are adopted. - HVM domain support To know the memory area to dump, XENMEM_set_memory_map is added. XENMEM_memory_map hypercall is for current domain, so new one is created. and hvm domain builder tell xen its