search for: pt_note

This patch updates x86_64 linker script to pack any .note.* sections into a PT_NOTE segment in the output file. To do this, we tell ld that we need a PT_NOTE segment. This requires us to start explicitly mapping sections to segments, so we also need to explicitly create PT_LOAD segments for text and data, and map the sections to them appropriately. Fortunately, each section wil...

vmcoreinfo file could exists under /sys/kernel (valid on baremetal only) and/or under /sys/hypervisor (valid when Xen dom0 is running). Read only one of them. It means that only one PT_NOTE will be always created. Remove extra code for second PT_NOTE creation. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> --- kexec/crashdump-elf.c | 33 +++++++-------------------------- 1 files changed, 7 insertions(+), 26 deletions(-) diff --git a/kexec/crashdump-elf.c b/kexec/cras...

Older binutils (prior to 2.16) have a problem with the linker script resulting from the change introducing explicit segment maps. Namely does the respective linker not properly handle @nobits sections (i.e. .bss) sitting between @progbits ones (i.e. .data.*). The .bss section must therefore be moved past all initialized sections (as is already the case on i386). Replacement patch attached. Jan

Hi Rusty, I had a look over your 011-paravirt-head.S.patch. I'm struggling to come up with a list of any benefits over having separate entrypoints for each hypervisor. Multiple entry pros: * allows maximum startup flexibility for any given hypervisor * for Xen at least, it's pretty simple * the "what hypervisor am I under" question is answered trivially cons:

...the off-by-one in reserving the top of address space has been fixed. For the most part, these patches do nothing or very little. The patches should be self explanatory, but the overview is: Helper functions for later use: 2/8: Implement always-locked bit ops... 8/8: Put .note.* sections into a PT_NOTE segment in vmlinux Cleanups: 1/8: Remove locally-defined ldt structure in favour of standard type 3/8: Allow a kernel to not be in ring 0 5/8: Roll all the cpuid asm into one __cpuid call Hooks: 4/8: Replace sensitive instructions with macros 6/8: Make __FIXADDR_TOP variable to allow it to m...

...the off-by-one in reserving the top of address space has been fixed. For the most part, these patches do nothing or very little. The patches should be self explanatory, but the overview is: Helper functions for later use: 2/8: Implement always-locked bit ops... 8/8: Put .note.* sections into a PT_NOTE segment in vmlinux Cleanups: 1/8: Remove locally-defined ldt structure in favour of standard type 3/8: Allow a kernel to not be in ring 0 5/8: Roll all the cpuid asm into one __cpuid call Hooks: 4/8: Replace sensitive instructions with macros 6/8: Make __FIXADDR_TOP variable to allow it to m...

...tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should be self explanatory, but the overview is: Helper functions for later use: 1/13: Add apply_to_page_range()... 3/13: Implement always-locked bit ops... 13/13: Put .note.* sections into a PT_NOTE segment in vmlinux Cleanups: 2/13: Remove locally-defined ldt structure in favour of standard type 4/13: Allow a kernel to not be in ring 0 6/13: Roll all the cpuid asm into one __cpuid call 9/13: Remove the read hazard from the COW path in copy_one_pte 10/13: Change pte_clear_full to a more...

...tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should be self explanatory, but the overview is: Helper functions for later use: 1/13: Add apply_to_page_range()... 3/13: Implement always-locked bit ops... 13/13: Put .note.* sections into a PT_NOTE segment in vmlinux Cleanups: 2/13: Remove locally-defined ldt structure in favour of standard type 4/13: Allow a kernel to not be in ring 0 6/13: Roll all the cpuid asm into one __cpuid call 9/13: Remove the read hazard from the COW path in copy_one_pte 10/13: Change pte_clear_full to a more...

...could also be like GCC and namespace our extensions > as ".note.LLVM.autolink", but maybe that's a step too far. > A .note section consists of a series of type-length-value records. My understanding is that the static linker aggregates them to a single location and put it into PT_NOTE segment, and the records can still be read by the loader even after the section table is stripped from an executable. For the proposed purpose, the note section header would not be useful or meaningful, so a plain section that just contains an ASCII string would be simpler. Reid > > On Thu,...

...sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) * sizeof(PHDR) + ranges * sizeof(PHDR); /* @@ -168,6 +175,21 @@ dbgprintf_phdr("vmcoreinfo header", phdr); } + if (has_vmcoreinfo_xen) { + phdr = (PHDR *) bufp; + bufp += sizeof(PHDR); + phdr->p_type = PT_NOTE; + phdr->p_flags = 0; + phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen; + phdr->p_vaddr = 0; + phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen; + /* Do we need any alignment of segments? */ + phdr->p_align = 0; + + (elf->e_phnum)++; + dbgprintf_phdr(&quo...

...nt PT_LOAD # p_type + .int kernel - bootsect_start # p_offset + .int LOAD_PHYSICAL_ADDR # p_vaddr + .int LOAD_PHYSICAL_ADDR # p_paddr + .int kernel_size # p_filesz + .int kernel_size # p_memsz + .int PF_R | PF_W | PF_X # p_flags + .int CONFIG_PHYSICAL_ALIGN # p_align + + .int PT_NOTE # p_type + .int notes - bootsect_start # p_offset + .int 0 # p_vaddr + .int 0 # p_paddr + .int notes_size # p_filesz + .int 0 # p_memsz + .int 0 # p_flags + .int 0 # p_align +e_phdr: start2: movw %cs, %ax @@ -97,9 +163,9 @@ bugger_off_msg: .section ".h...

...nt PT_LOAD # p_type + .int kernel - bootsect_start # p_offset + .int LOAD_PHYSICAL_ADDR # p_vaddr + .int LOAD_PHYSICAL_ADDR # p_paddr + .int kernel_size # p_filesz + .int kernel_size # p_memsz + .int PF_R | PF_W | PF_X # p_flags + .int CONFIG_PHYSICAL_ALIGN # p_align + + .int PT_NOTE # p_type + .int notes - bootsect_start # p_offset + .int 0 # p_vaddr + .int 0 # p_paddr + .int notes_size # p_filesz + .int 0 # p_memsz + .int 0 # p_flags + .int 0 # p_align +e_phdr: start2: movw %cs, %ax @@ -97,9 +163,9 @@ bugger_off_msg: .section ".h...

...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); + + phdr->p_vaddr += new_base - old_base; + switch(phdr->p_type) { + case PT_LOAD: + case PT_NOTE: + break; + case PT_DYNAMIC: { + Elf32_Dyn *dyn = (void *)(phdr->p_vaddr - new_base + (unsigned long)ehdr); + unsigned j; + + for(j = 0; dyn[j].d_tag != DT_NULL; ++j) { + switch(dyn[j].d_tag) { + case DT_HASH: + case DT_STRTAB: + case DT_SYMTAB: + case 0x6ffffff0:...

...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); + + phdr->p_vaddr += new_base - old_base; + switch(phdr->p_type) { + case PT_LOAD: + case PT_NOTE: + break; + case PT_DYNAMIC: { + Elf32_Dyn *dyn = (void *)(phdr->p_vaddr - new_base + (unsigned long)ehdr); + unsigned j; + + for(j = 0; dyn[j].d_tag != DT_NULL; ++j) { + switch(dyn[j].d_tag) { + case DT_HASH: + case DT_STRTAB: + case DT_SYMTAB: + case 0x6ffffff0:...

...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); + + phdr->p_vaddr += new_base - old_base; + switch(phdr->p_type) { + case PT_LOAD: + case PT_NOTE: + break; + case PT_DYNAMIC: { + Elf32_Dyn *dyn = (void *)(phdr->p_vaddr - new_base + (unsigned long)ehdr); + unsigned j; + + for(j = 0; dyn[j].d_tag != DT_NULL; ++j) { + switch(dyn[j].d_tag) { + case DT_HASH: + case DT_STRTAB: + case DT_SYMTAB: + case 0x6ffffff0:...

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen

The ELF file header isn't always covered by a segment but still affects loading. I think everything else that effects loading/dynamic linking is always covered by a PT_LOAD segment. As evidence this is basically what --strip-sections in llvm-strip and eu-strip do and they produce perfectly runnable binaries. Having a hash of the actual memory map is interesting IMO. Build IDs can't really

The attached re-enables the pygrub build and fixes the build with older e2fsprogs (tested on RHEL4 with e2fsprogs-1.35 and rawhide with e2fsprogs-1.38) Signed-off-by: Jeremy Katz <katzj@redhat.com> Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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