search for: elfdata2lsb

?The idea itself is indeed good. Regarding to escaping: I think we should have it. Imagine the following example (I've took it from D73828). --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2LSB Type: ET_EXEC Machine: EM_386 # RUN: yaml2obj %s --docnum=4 -D BITS=32 -o %t-32bit.o # RUN: yaml2obj %s --docnum=4 -D BITS=64 -o %t-64bit.o Without escaping it would be: Class: ELFCLASSBITS What does not look so clear as a version with escaping IMO. Best regards, George | Developer...

...-local was installed and then reinstalled it anyway, but the libsendfile.so.1 was not located in /usr/bin where it is located on my other server with the older version of Samba. I tried manually copying the files over and got this error: fatal: /usr/local/lib/libiconv.so.2: wrong ELF data format: ELFDATA2LSB What could I be screwing up? Thanks, Dave ___________________________________________________________________ The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure...

..., and others) 3. A value can 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: libsome...

...> sizeof(Elf32_Ehdr) && + BOOTABLE_I386_ELF((*((Elf32_Ehdr *) load_addr))))) { - /* 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); -...

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

...ong dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_ON(ehdr->e_ident[EI_DATA] != ELFDATA2LSB); + BUG_ON(ehdr->e_ehsize < sizeof(*ehdr)); + ehdr->e_entry += new_base - old_base; + BUG_ON(ehdr->e_phentsize < sizeof(Elf32_Phdr)); + for (i = 0; i < ehdr->e_phnum; ++i) { + Elf32_Phdr *phdr = (void *)((unsigned long)ehdr + ehdr->e_phoff + i * ehdr->e_phentsize); + +...

...ong dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_ON(ehdr->e_ident[EI_DATA] != ELFDATA2LSB); + BUG_ON(ehdr->e_ehsize < sizeof(*ehdr)); + ehdr->e_entry += new_base - old_base; + BUG_ON(ehdr->e_phentsize < sizeof(Elf32_Phdr)); + for (i = 0; i < ehdr->e_phnum; ++i) { + Elf32_Phdr *phdr = (void *)((unsigned long)ehdr + ehdr->e_phoff + i * ehdr->e_phentsize); + +...

...ong dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_ON(ehdr->e_ident[EI_DATA] != ELFDATA2LSB); + BUG_ON(ehdr->e_ehsize < sizeof(*ehdr)); + ehdr->e_entry += new_base - old_base; + BUG_ON(ehdr->e_phentsize < sizeof(Elf32_Phdr)); + for (i = 0; i < ehdr->e_phnum; ++i) { + Elf32_Phdr *phdr = (void *)((unsigned long)ehdr + ehdr->e_phoff + i * ehdr->e_phentsize); + +...

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

...print the bugger off message. + # The 1 stores to bx+di is unfortunate it is + # unlikely to affect the ability to print + # a message and you aren't supposed to be booting a + # bzImage directly from a floppy anyway. + + # e_ident + .byte ELFMAG0, ELFMAG1, ELFMAG2, ELFMAG3 + .byte ELFCLASS32, ELFDATA2LSB, EV_CURRENT, ELFOSABI_STANDALONE + .byte 0xeb, 0x3d, 0, 0, 0, 0, 0, 0 +#ifndef CONFIG_RELOCATABLE + .word ET_EXEC # e_type +#else + .word ET_DYN # e_type +#endif + .word EM_386 # e_machine + .int 1 # e_version + .int LOAD_PHYSICAL_ADDR # e_entry + .int phdr - bootsect_start # e_ph...

...print the bugger off message. + # The 1 stores to bx+di is unfortunate it is + # unlikely to affect the ability to print + # a message and you aren't supposed to be booting a + # bzImage directly from a floppy anyway. + + # e_ident + .byte ELFMAG0, ELFMAG1, ELFMAG2, ELFMAG3 + .byte ELFCLASS32, ELFDATA2LSB, EV_CURRENT, ELFOSABI_STANDALONE + .byte 0xeb, 0x3d, 0, 0, 0, 0, 0, 0 +#ifndef CONFIG_RELOCATABLE + .word ET_EXEC # e_type +#else + .word ET_DYN # e_type +#endif + .word EM_386 # e_machine + .int 1 # e_version + .int LOAD_PHYSICAL_ADDR # e_entry + .int phdr - bootsect_start # e_ph...

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

[ 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

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

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 adds fields to specify the hardware subarchitecture and some

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 adds fields to specify the hardware subarchitecture and some

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 adds fields to specify the hardware subarchitecture and some