search for: phdrs

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,56 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + void *dest; + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3)...

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,56 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + void *dest; + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3)...

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,49 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3) + { + error(...

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,49 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3) + { + error(...

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,56 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + void *dest; + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3)...

..._info.h> +#include <linux/elf.h> #include <asm/io.h> #include <asm/page.h> #include <asm/boot.h> @@ -365,6 +370,56 @@ static void error(char *x) asm("hlt"); } +static void parse_elf(void *output) +{ +#ifdef CONFIG_X86_64 + Elf64_Ehdr ehdr; + Elf64_Phdr *phdrs, *phdr; +#else + Elf32_Ehdr ehdr; + Elf32_Phdr *phdrs, *phdr; +#endif + void *dest; + int i; + + memcpy(&ehdr, output, sizeof(ehdr)); + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 || + ehdr.e_ident[EI_MAG1] != ELFMAG1 || + ehdr.e_ident[EI_MAG2] != ELFMAG2 || + ehdr.e_ident[EI_MAG3] != ELFMAG3)...

...generated headers differently (well, that's at least how I see it at the moment). I think, if the headers are custom, they may not appear in the address space, otherwise they (always?) do. I came up with this conclusion because adding the following command appears to produce a correct binary: PHDRS { main PT_LOAD; } Elf file type is EXEC (Executable file) Entry point 0x80002670 There are 1 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x80000000 0x80000000 0x09098 0x09098 RWE 0x1...

...ine/test it's hard to be sure > <andrewrk> the not working elf file has only 1 .rodata section > <andrewrk> here's the difference between bad and good headers: > https://clbin.com/vvB8O > <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs > <tomhughes> don't think it's the problem but this file is quite odd - the > ro segment in the phdrs doesn't seem to have to any section listed in the > shdrs > <tomhughes> s/have/map/ > > Is this something where LLD can be reasonably changed to be compati...

...n executable to examine/test it's hard to be sure <andrewrk> the not working elf file has only 1 .rodata section <andrewrk> here's the difference between bad and good headers: https://clbin.com/vvB8O <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs <tomhughes> don't think it's the problem but this file is quite odd - the ro segment in the phdrs doesn't seem to have to any section listed in the shdrs <tomhughes> s/have/map/ Is this something where LLD can be reasonably changed to be compatible with valgrind without thi...

...The SHF_ALLOC output sections are first sorted by partition, and then by the usual sorting rules. As usual, non-SHF_ALLOC sections appear last and are not sorted by partition. In the end we are left with a collection of output sections that might look like this: Main partition: 0x0000 ELF header, phdrs 0x1000 .rodata 0x2000 .dynsym 0x3000 .text Loadable partition 1: 0x4000 ELF header, phdrs 0x5000 .rodata 0x6000 .dynsym 0x7000 .text Loadable partition 2: 0x8000 ELF header, phdrs 0x9000 .rodata 0xa000 .dynsym 0xb000 .text Non-SHF_ALLOC sections from all partitions: .comment .debug_info (etc.)...

...s hard to be sure >> <andrewrk> the not working elf file has only 1 .rodata section >> <andrewrk> here's the difference between bad and good headers: >> https://clbin.com/vvB8O >> <tomhughes> ah I see it's because it's a mapped ro segment in the phdrs >> <tomhughes> don't think it's the problem but this file is quite odd - the >> ro segment in the phdrs doesn't seem to have to any section listed in the >> shdrs >> <tomhughes> s/have/map/ >> >> Is this something where LLD can be reasonab...

As a frontend, what are the downsides of enabling --no-rosegment by default? So far the pro list is: * valgrind debug info will work by default What's on the con list? On Thu, Apr 5, 2018 at 5:16 PM, Shoaib Meenai <smeenai at fb.com> wrote: > It's more of a valgrind issue than an LLD issue, but you can work around > it by linking with --no-rosegment > > > >

...t;> partition, and then by the usual sorting rules. As usual, non-SHF_ALLOC >> sections appear last and are not sorted by partition. In the end we are >> left with a collection of output sections that might look like this: >> >> Main partition: >> 0x0000 ELF header, phdrs >> 0x1000 .rodata >> 0x2000 .dynsym >> 0x3000 .text >> >> Loadable partition 1: >> 0x4000 ELF header, phdrs >> 0x5000 .rodata >> 0x6000 .dynsym >> 0x7000 .text >> >> Loadable partition 2: >> 0x8000 ELF header, phdrs >> 0x...

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05

...e = eh64->e_shentsize; + mbinfo.syms.e.shndx = eh64->e_shstrndx; + + for (i = 0; i < eh64->e_shnum; i++) { + addr_t align; + + if (!sh64[i].sh_size) + continue; /* Empty section */ + if (sh64[i].sh_flags & SHF_ALLOC) + continue; /* SHF_ALLOC sections should have PHDRs */ + + align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; + addr = map_data((char *)ptr + sh64[i].sh_offset, + sh64[i].sh_size, align, MAP_HIGH); + if (!addr) { + error("Failed to map symbol section\n"); + return NULL; + } + sh64[i].sh_addr = addr; } }...

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the COMPAT_VDSO work happens at runtime now, and allows compat mode to be enabled dynamically. If you specify vdso=2 on the kernel command line, it comes up in compat mode; vdso=1 is n...

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the COMPAT_VDSO work happens at runtime now, and allows compat mode to be enabled dynamically. If you specify vdso=2 on the kernel command line, it comes up in compat mode; vdso=1 is n...

...ith flat 4G segments 4. there may or may not be a valid GDT (segment registers must not be reloaded until GDT is explicitly set up) 5. interrupts disabled 6. paging may or may not be enabled; if enabled, it has 1:1 mappings where the ELF file's Phdrs say they should be 6. When bzImage starts the kernel-proper, it works out how to choose the appropriate boot path based on the boot info structure in %esi How much of this already exists? Is there enough to start prototyping with? What was the problem with ELF bzImage? Is it confirmed...

...ith flat 4G segments 4. there may or may not be a valid GDT (segment registers must not be reloaded until GDT is explicitly set up) 5. interrupts disabled 6. paging may or may not be enabled; if enabled, it has 1:1 mappings where the ELF file's Phdrs say they should be 6. When bzImage starts the kernel-proper, it works out how to choose the appropriate boot path based on the boot info structure in %esi How much of this already exists? Is there enough to start prototyping with? What was the problem with ELF bzImage? Is it confirmed...

...data; we use this to store the Xen start_info pointer. 2. The 32-part of the bzImage code, which includes a decompressor and the compressed data for the actual kernel, is wrapped in an ELF file. This allows us to decorate it with the Xen-spceific ELF notes, and also use the PHDRs to specify how much memory Xen needs to map initially. The ELF file is constructed so that the PHDRs map enough memory for the kernel to decompress itself, and run enough until it can build its own initial pagetables. The Linux boot protocol requires that %esi point to the boot...