search for: output_arch

...- * (at your option) any later version; incorporated herein by reference. - * - * ----------------------------------------------------------------------- */ - -/* - * Linker script for the SYSLINUX core - */ - -OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") -OUTPUT_ARCH(i386) -EXTERN(_start) -ENTRY(_start) - -STACK32_LEN = 65536; - -SECTIONS -{ - /* Prefix structure for the compression program */ - . = 0; - HIDDEN(__module_start = .); - .prefix : { - *(.prefix) - } - - /* "Early" sections (before the load) */ - . = 0x1000; - - .earlybss (NOLOAD) : { -...

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

Hi, I am trying to build a simple xen guest kernel for x86_64. I am having an issue with the linker flags. Setting the OUTPUT_ARCH(i386:x86_64) works but gives warnings. and the guest kernel crashes when started with xm create. Any suggestions? thanks, Harsha _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

When I compile klibc on little-endian mips, I get: KLIBCLD klibc/libc.so ld: klibc/arch/mips/crt0.o: compiled for a little endian system and target is big endian ld: klibc/arch/mips/crt0.o: endianness incompatible with that of the selected emulation ld: failed to merge target specific data of file klibc/arch/mips/crt0.o When I change "elf32-tradbigmips" to

...inux.lds +++ b/arch/i386/boot/compressed/vmlinux.lds @@ -1,13 +1,12 @@ OUTPUT_FORMAT("elf32-i386", "elf32-i386" -OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") +/* OUTPUT_FORMAT("binary") */ +OUTPUT_FORMAT("elf32-i386") OUTPUT_ARCH(i386) ENTRY(startup_32) SECTIONS { - /* Be careful parts of head.S assume startup_32 is at - * address 0. - */ . = 0 ; .text.head : { + *(.elfhdr) _head = . ; *(.text.head) _ehead = . ; @@ -33,6 +32,7 @@ SECTIONS *(.data.*) _edata = . ; } + _filesz = . ;...

...inux.lds +++ b/arch/i386/boot/compressed/vmlinux.lds @@ -1,13 +1,12 @@ OUTPUT_FORMAT("elf32-i386", "elf32-i386" -OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") +/* OUTPUT_FORMAT("binary") */ +OUTPUT_FORMAT("elf32-i386") OUTPUT_ARCH(i386) ENTRY(startup_32) SECTIONS { - /* Be careful parts of head.S assume startup_32 is at - * address 0. - */ . = 0 ; .text.head : { + *(.elfhdr) _head = . ; *(.text.head) _ehead = . ; @@ -33,6 +32,7 @@ SECTIONS *(.data.*) _edata = . ; } + _filesz = . ;...

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:

...lt;ian.campbell@xensource.com> diff --git a/arch/x86_64/kernel/vmlinux.lds.S b/arch/x86_64/kernel/vmlinux.lds.S index 7c4de31..ef418b3 100644 --- a/arch/x86_64/kernel/vmlinux.lds.S +++ b/arch/x86_64/kernel/vmlinux.lds.S @@ -13,6 +13,12 @@ OUTPUT_FORMAT("elf64-x86-64", "elf64-x86 OUTPUT_ARCH(i386:x86-64) ENTRY(phys_startup_64) jiffies_64 = jiffies; +PHDRS { + text PT_LOAD FLAGS(5); /* R_E */ + data PT_LOAD FLAGS(7); /* RWE */ + user PT_LOAD FLAGS(7); /* RWE */ + note PT_NOTE FLAGS(4); /* R__ */ +} SECTIONS { . = __START_KERNEL; @@ -31,7 +37,7 @@ SECTIONS KPROBES_TEXT *(.fixu...

[ 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

.../* Top level commands which we ignore. The GNU linker uses these to * select the output format, but we don't offer a choice. Ignoring * these is more-or-less OK since most scripts simply explicitly * choose the default. */ * ignore_cmd: * OUTPUT_ARCH '(' string ')' * ; */ OUTPUT_ARCH(hppa:hppa2.0w) /* This specifies the entry symbol. Equivalent to `-e`/`--entry`*/ ENTRY(__start) /* This defines the program headers that should be present in the output. * Output section descriptions inside the SECTIONS command...

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

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