Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? Thanks, Dscho
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 6/28/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? OpenBIOS SVN, not QEMU.
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: On 6/28/07, Johannes Schindelin [EMAIL PROTECTED] wrote: On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? OpenBIOS SVN, not QEMU. Ah, thanks. Ciao, Dscho
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote: On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M. #define ELF_MAXPAGESIZE 0x10 BFD and GNU ld think it's 1MB. I stand corrected. Is there anything that can be done to reduce this waste?
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Blue Swirl wrote: On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote: On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M. #define ELF_MAXPAGESIZE 0x10 BFD and GNU ld think it's 1MB. I stand corrected. Is there anything that can be done to reduce this waste? See ld's -z max-page-size and -z common-page-size. Thiemo
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 06:01:04PM +0300, Blue Swirl wrote: I stand corrected. Is there anything that can be done to reduce this waste? For a BIOS image, you might be OK with ld -N - that should suppress the padding. Thanks, size is smaller and Qemu still accepts the image. I'll update the image and rules.
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
The Sparc64 image is much larger than the Sparc32 image, but the size command displays a much smaller text and data size (about the same size as for the Sparc32 image). Maybe it contains some unneeded parts? Stefan Blue Swirl schrieb: CVSROOT: /cvsroot/qemu Module name: qemu Changes by: Blue Swirl blueswir1 07/04/15 06:38:29 Modified files: pc-bios: README openbios-sparc32 Added files: pc-bios: openbios-sparc64 Log message: Update OpenBIOS for Sparc32 and add a Sparc64 image
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/15/07, Stefan Weil [EMAIL PROTECTED] wrote: The Sparc64 image is much larger than the Sparc32 image, but the size command displays a much smaller text and data size (about the same size as for the Sparc32 image). Maybe it contains some unneeded parts? Thanks for the report. There is indeed a whole lot of unused space between ELF header and start of .text segment. But I don't see what in the ldscript (attached) causes the gap to appear. Suggestions? ldscript Description: Binary data
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On Sunday 15 April 2007 16:03, Blue Swirl wrote: On 4/15/07, Stefan Weil [EMAIL PROTECTED] wrote: The Sparc64 image is much larger than the Sparc32 image, but the size command displays a much smaller text and data size (about the same size as for the Sparc32 image). Maybe it contains some unneeded parts? Thanks for the report. There is indeed a whole lot of unused space between ELF header and start of .text segment. But I don't see what in the ldscript (attached) causes the gap to appear. Suggestions? Probably the linker is making sure the file offset and VMA are the same modulo the page size. For our purposes we don't care about this. On an OS with virtual memory this means the image can be mmapped drectly into memory. Paul
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: pc-bios/openbios-sparc64: file format elf64-sparc pc-bios/openbios-sparc64 architecture: sparc:v9, flags 0x0102: EXEC_P, D_PAGED start address 0x01fff000 Program Header: LOAD off0x0010 vaddr 0x01fff000 paddr 0x01fff000 align 2**20 filesz 0x000600c0 memsz 0x000f5000 flags rwx STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text 00028bd0 01fff000 01fff000 0010 2**14 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 0002cdbc 01fff003 01fff003 0013 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 00c0 01fff006 01fff006 0016 2**3 CONTENTS, ALLOC, LOAD, DATA 3 .bss 00094000 01fff0061000 01fff0061000 001600c0 2**3 ALLOC SYMBOL TABLE: no symbols
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Paul
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M.
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote: On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M. #define ELF_MAXPAGESIZE 0x10 BFD and GNU ld think it's 1MB. -- Daniel Jacobowitz CodeSourcery
