Jeremy Fitzhardinge <[email protected]> writes:
> Andi Kleen wrote:
>>> +#ifdef CONFIG_XEN
>>> +#include "../xen/xen-head.S"
>>> +#endif
>>>
>>
>> Can this really not be linked separately?
>
> I did a patch to do this (attached). In principle it should be pretty
> simple, but I think I'm running into toolchain issues. If I link
> xen-head.S separately (with appropriate headers added), it compiles OK
> and contains the right notes, but they don't appear in the final vmlinux
> properly. The note segment and section are there, but no tools will
> parse them as notes:
>
> : ezr:pts/1; readelf -n vmlinux
> : ezr:pts/1; ../../unstable/tools/xcutils/readnotes vmlinux
> : ezr:pts/1; readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x2e1f70
> There are 3 program headers, starting at offset 52
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x001000 0xc0100000 0x00100000 0x2a8920 0x2a8920 R E 0x1000
> LOAD 0x2aa000 0xc03a9000 0x003a9000 0x5f085 0xaf000 RWE 0x1000
> NOTE 0x26d2910 0x00239010 0x00239010 0x000e8 0x00000 R 0x4
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text .text.head __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __kcrctab __kcrctab_gpl __ksymtab_strings __param __bug_table
> 01 .data .paravirtprobe .data_nosave .data.page_aligned
> .data.cacheline_aligned .data.read_mostly .data.init_task .init.text .init.data
> .init.setup .initcall.init .con_initcall.init .altinstructions
> .altinstr_replacement .parainstructions .exit.text .init.ramfs .bss
> 02 .notes
> : ezr:pts/1; objdump -j .notes -s vmlinux
>
> vmlinux: file format elf32-i386
>
> Contents of section .notes:
> 239010 04000000 06000000 06000000 58656e00 ............Xen.
> 239020 6c696e75 78000000 04000000 04000000 linux...........
> 239030 07000000 58656e00 322e3600 04000000 ....Xen.2.6.....
> 239040 08000000 05000000 58656e00 78656e2d ........Xen.xen-
> 239050 332e3000 04000000 04000000 03000000 3.0.............
> 239060 58656e00 000000c0 04000000 04000000 Xen.............
> 239070 01000000 58656e00 c80710c0 04000000 ....Xen.........
> 239080 04000000 02000000 58656e00 00b040c0 ........Xen...@.
> 239090 04000000 2a000000 0a000000 58656e00 ....*.......Xen.
> 2390a0 21777269 7461626c 655f7061 67655f74 !writable_page_t
> 2390b0 61626c65 737c7061 655f7067 6469725f ables|pae_pgdir_
> 2390c0 61626f76 655f3467 62000000 04000000 above_4gb.......
> 2390d0 04000000 09000000 58656e00 79657300 ........Xen.yes.
> 2390e0 04000000 08000000 08000000 58656e00 ............Xen.
> 2390f0 67656e65 72696300 generic.
>
>
> I can't see what the problem is here, but it looks like a toolchain
> problem to me (I'm using binutils-2.17.50.0.6-2.fc6).
Well I did a little by hand parsing and the not I parsed looked ok.
How does the output differ from a what you get when xen-head.S is
included?
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]