[Qemu-devel] qemu Changelog hw/slavio_timer.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/07 10:00:55 Modified files: . : Changelog hw : slavio_timer.c Log message: More user timer fixes (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.141r2=1.142 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_timer.c?cvsroot=qemur1=1.17r2=1.18
[Qemu-devel] x86 -cpu option: Take 4
Hi,
Due to comments on Take 3, I rewrote the feature name list according
to Intel's and AMD's specs in order not to contaminate target-i386 with
GPL code. More importantly - the host cpu type is dropped. It will be
added, as a kvm-specific code, in a future patch.
I'd be happy to hear if patch is applicable in its current minimalistic
form this, or that more changes should be made.
Thanks,
Dan.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.346
diff -u -p -r1.346 vl.c
--- vl.c5 Oct 2007 13:08:34 - 1.346
+++ vl.c7 Oct 2007 12:34:45 -
@@ -7696,6 +7696,8 @@ int main(int argc, char **argv)
mips_cpu_list(stdout, fprintf);
#elif defined(TARGET_SPARC)
sparc_cpu_list(stdout, fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, fprintf);
#endif
exit(0);
} else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.86
diff -u -p -r1.86 pc.c
--- hw/pc.c 5 Oct 2007 13:08:35 - 1.86
+++ hw/pc.c 7 Oct 2007 12:34:46 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = basic;
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, Unable to find x86 CPU definition\n);
+exit(1);
+}
for(i = 0; i smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -950,7 +957,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -964,7 +971,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.50
diff -u -p -r1.50 cpu.h
--- target-i386/cpu.h 27 Sep 2007 16:44:31 - 1.50
+++ target-i386/cpu.h 7 Oct 2007 12:34:46 -
@@ -274,23 +274,56 @@
#define CPUID_CMOV (1 15)
#define CPUID_PAT (1 16)
#define CPUID_PSE36 (1 17)
+#define CPUID_PN (1 18)
#define CPUID_CLFLUSH (1 19)
-/* ... */
+#define CPUID_DTS (1 21)
+#define CPUID_ACPI (1 22)
#define CPUID_MMX (1 23)
#define CPUID_FXSR (1 24)
#define CPUID_SSE (1 25)
#define CPUID_SSE2 (1 26)
+#define CPUID_SS (1 27)
+#define CPUID_HT (1 28)
+#define CPUID_TM (1 29)
+#define CPUID_IA64 (1 30)
+#define CPUID_PBE (1 31)
#define CPUID_EXT_SSE3 (1 0)
#define CPUID_EXT_MONITOR (1 3)
+#define CPUID_EXT_DSCPL(1 4)
+#define CPUID_EXT_VMX (1 5)
+#define CPUID_EXT_SMX (1 6)
+#define CPUID_EXT_EST (1 7)
+#define CPUID_EXT_TM2 (1 8)
+#define CPUID_EXT_SSSE3(1 9)
+#define CPUID_EXT_CID (1 10)
#define CPUID_EXT_CX16 (1 13)
+#define CPUID_EXT_XTPR (1 14)
+#define CPUID_EXT_DCA (1 17)
+#define CPUID_EXT_POPCNT (1 22)
#define CPUID_EXT2_SYSCALL (1 11)
+#define CPUID_EXT2_MP (1 19)
#define CPUID_EXT2_NX (1 20)
+#define CPUID_EXT2_MMXEXT (1 22)
#define CPUID_EXT2_FFXSR (1 25)
+#define CPUID_EXT2_PDPE1GB (1 26)
+#define CPUID_EXT2_RDTSCP (1 27)
#define CPUID_EXT2_LM (1 29)
+#define CPUID_EXT2_3DNOWEXT (1 30)
+#define CPUID_EXT2_3DNOW (1 31)
+#define CPUID_EXT3_LAHF_LM (1 0)
+#define CPUID_EXT3_CMP_LEG (1 1)
#define CPUID_EXT3_SVM (1 2)
+#define CPUID_EXT3_EXTAPIC (1 3)
+#define CPUID_EXT3_CR8LEG (1 4)
+#define CPUID_EXT3_ABM (1 5)
+#define CPUID_EXT3_SSE4A (1 6)
+#define CPUID_EXT3_MISALIGNSSE (1 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 8)
+#define CPUID_EXT3_OSVW(1 9)
+#define CPUID_EXT3_IBS (1 10)
#define EXCP00_DIVZ0
#define EXCP01_SSTP1
@@ -564,6 +597,9 @@ typedef struct CPUX86State {
CPUX86State *cpu_x86_init(void);
int cpu_x86_exec(CPUX86State *s);
void cpu_x86_close(CPUX86State *s);
+int
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: Hi, Hi, This patch adds support for loading a 32 bit ELF file in the 64 bit user mode emulator. This means that qemu-sparc64 can be used to execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). This format is used by Solaris/Sparc and maybe by Debian in the future. Other targets shouldn't be affected, but I have done only compile testing. Any comments? The idea of loading 32 bits executables on 64 bits target seems great. Then, I got two remarks about this patch: - it seems that it does not take care about my patch. As I was to commit it today, I wonder if I still should do it. But then, your patch lacks some bugifxes (start_data not properly computed and TARGET_LONG_BITS != HOST_LONG_BITS problems). - it seems that quite all the ELF loader code is affected by your patch. I think (maybe too naively) that adding functions to read the ELF infos should be sufficient, ie add a read_elf_ehdr, ..., functions and a few patches in the create_elf_table function. Then, all informations nedded to load a 32 bits executable can be kept into the 64 bits structures. As the kernel does not duplicate the code to handle this case, I think Qemu loader should be kept as simple as the kernel one, and the elfload_ops.h seems to me to be useless. In fact, Qemu loader could (should ?) even be the same code than the kernel one with just a few helpers for endianness swaps and the needed fixes to avoid confusions between host_long and target_long... -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] [PATCH] usb-linux iso: use pipe instead of bh
When handling the isocronous completion signals, use O_NONBLOCK pipe instead of bottom halves for thread-safety. usb-linux.patch Description: usb-linux.patch
[Qemu-devel] qemu/hw ppc405.h ppc405_uc.c ppc4xx.h ppc4xx_de...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 14:21:26 Modified files: hw : ppc405.h ppc405_uc.c Added files: hw : ppc4xx.h ppc4xx_devs.c Log message: Share devices that might be useful for all PowerPC 40x 440 implementations (mostly CPU registration and UIC, for now). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405.h?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc4xx.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc4xx_devs.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 14:25:11 Modified files: . : Makefile.target Log message: Share devices that may be useful for all PowerPC 40x and 440 implementations. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.204r2=1.205
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: Hi, Hi, This patch adds support for loading a 32 bit ELF file in the 64 bit user mode emulator. This means that qemu-sparc64 can be used to execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). This format is used by Solaris/Sparc and maybe by Debian in the future. Other targets shouldn't be affected, but I have done only compile testing. Any comments? The idea of loading 32 bits executables on 64 bits target seems great. Then, I got two remarks about this patch: - it seems that it does not take care about my patch. As I was to commit it today, I wonder if I still should do it. But then, your patch lacks some bugifxes (start_data not properly computed and TARGET_LONG_BITS != HOST_LONG_BITS problems). Well, I thought that you had already applied the patch. - it seems that quite all the ELF loader code is affected by your patch. I think (maybe too naively) that adding functions to read the ELF infos should be sufficient, ie add a read_elf_ehdr, ..., functions and a few patches in the create_elf_table function. Then, all informations nedded to load a 32 bits executable can be kept into the 64 bits structures. As the kernel does not duplicate the code to handle this case, I think Qemu loader should be kept as simple as the kernel one, and the elfload_ops.h seems to me to be useless. In fact, Qemu loader could (should ?) even be the same code than the kernel one with just a few helpers for endianness swaps and the needed fixes to avoid confusions between host_long and target_long... Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which #includes fs/binfmt_elf.c. 64 bit V9 binaries are handled by fs/binfmt_elf.c. In Qemu we can't do it like this, because V9 instruction emulator must be used to handle also the 32 bit ELF. The same effect could be achieved in Qemu for example by adding new file elfload_32.c, which would include elfload.c after defining the ELF classes etc. This would need some rearranging in elfload.c so that the ELF parameters can be overridden. I'm not sure this would be much cleaner than my version using glue().
[Qemu-devel] qemu/target-ppc cpu.h helper.c translate.c tran...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 14:41:00 Modified files: target-ppc : cpu.h helper.c translate.c translate_init.c Log message: Add MSR bits signification per PowerPC implementation flags (to be continued). As a side effect, single step and branch step are available again. Remove irrelevant MSR bits definitions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.73r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.69r2=1.70 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.86r2=1.87 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.43r2=1.44
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote: On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: Hi, Hi, This patch adds support for loading a 32 bit ELF file in the 64 bit user mode emulator. This means that qemu-sparc64 can be used to execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). This format is used by Solaris/Sparc and maybe by Debian in the future. Other targets shouldn't be affected, but I have done only compile testing. Any comments? The idea of loading 32 bits executables on 64 bits target seems great. Then, I got two remarks about this patch: - it seems that it does not take care about my patch. As I was to commit it today, I wonder if I still should do it. But then, your patch lacks some bugifxes (start_data not properly computed and TARGET_LONG_BITS != HOST_LONG_BITS problems). Well, I thought that you had already applied the patch. OK, do you agree that I apply it and you take the changes in yours ? - it seems that quite all the ELF loader code is affected by your patch. I think (maybe too naively) that adding functions to read the ELF infos should be sufficient, ie add a read_elf_ehdr, ..., functions and a few patches in the create_elf_table function. Then, all informations nedded to load a 32 bits executable can be kept into the 64 bits structures. As the kernel does not duplicate the code to handle this case, I think Qemu loader should be kept as simple as the kernel one, and the elfload_ops.h seems to me to be useless. In fact, Qemu loader could (should ?) even be the same code than the kernel one with just a few helpers for endianness swaps and the needed fixes to avoid confusions between host_long and target_long... Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which #includes fs/binfmt_elf.c. 64 bit V9 binaries are handled by fs/binfmt_elf.c. In Qemu we can't do it like this, because V9 instruction emulator must be used to handle also the 32 bit ELF. The same effect could be achieved in Qemu for example by adding new file elfload_32.c, which would include elfload.c after defining the ELF classes etc. This would need some rearranging in elfload.c so that the ELF parameters can be overridden. I'm not sure this would be much cleaner than my version using glue(). OK, then if the kernel duplicates the compiled code, it means that this way of doing might be the proper one. Couldn't you do something closest to what the kernel do, ie moving the per target definitions located at the top of elfload.c somewhere else and add a elfload_32.c file that would include elfload.c redefining all needed variable types, ... ? This just to keep the code as close as possible to the kernel one, even if it functionnaly changes nothing... -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote: On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: Hi, Hi, This patch adds support for loading a 32 bit ELF file in the 64 bit user mode emulator. This means that qemu-sparc64 can be used to execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). This format is used by Solaris/Sparc and maybe by Debian in the future. Other targets shouldn't be affected, but I have done only compile testing. Any comments? The idea of loading 32 bits executables on 64 bits target seems great. Then, I got two remarks about this patch: - it seems that it does not take care about my patch. As I was to commit it today, I wonder if I still should do it. But then, your patch lacks some bugifxes (start_data not properly computed and TARGET_LONG_BITS != HOST_LONG_BITS problems). Well, I thought that you had already applied the patch. OK, do you agree that I apply it and you take the changes in yours ? Yes, the patch looks OK (haven't tested it) and if something still breaks, we can fix it. - it seems that quite all the ELF loader code is affected by your patch. I think (maybe too naively) that adding functions to read the ELF infos should be sufficient, ie add a read_elf_ehdr, ..., functions and a few patches in the create_elf_table function. Then, all informations nedded to load a 32 bits executable can be kept into the 64 bits structures. As the kernel does not duplicate the code to handle this case, I think Qemu loader should be kept as simple as the kernel one, and the elfload_ops.h seems to me to be useless. In fact, Qemu loader could (should ?) even be the same code than the kernel one with just a few helpers for endianness swaps and the needed fixes to avoid confusions between host_long and target_long... Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which #includes fs/binfmt_elf.c. 64 bit V9 binaries are handled by fs/binfmt_elf.c. In Qemu we can't do it like this, because V9 instruction emulator must be used to handle also the 32 bit ELF. The same effect could be achieved in Qemu for example by adding new file elfload_32.c, which would include elfload.c after defining the ELF classes etc. This would need some rearranging in elfload.c so that the ELF parameters can be overridden. I'm not sure this would be much cleaner than my version using glue(). OK, then if the kernel duplicates the compiled code, it means that this way of doing might be the proper one. Couldn't you do something closest to what the kernel do, ie moving the per target definitions located at the top of elfload.c somewhere else and add a elfload_32.c file that would include elfload.c redefining all needed variable types, ... ? This just to keep the code as close as possible to the kernel one, even if it functionnaly changes nothing... I'll try if that works. It could be a better approach after all.
[Qemu-devel] qemu/target-ppc cpu.h translate.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 15:43:50 Modified files: target-ppc : cpu.h translate.c translate_init.c Log message: Reorganize the CPUPPCState structure to group features. Add #ifdef to avoid compiling not relevant resources: - MMU related stuff for user-mode only targets - PowerPC 64 only resources for PowerPC 32 targets - embedded PowerPC extensions for non-ppcemb targets. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.74r2=1.75 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.87r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.44r2=1.45
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
On Sun, 2007-10-07 at 18:15 +0300, Blue Swirl wrote: On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote: On 10/7/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: Hi, Hi, This patch adds support for loading a 32 bit ELF file in the 64 bit user mode emulator. This means that qemu-sparc64 can be used to execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). This format is used by Solaris/Sparc and maybe by Debian in the future. Other targets shouldn't be affected, but I have done only compile testing. Any comments? The idea of loading 32 bits executables on 64 bits target seems great. Then, I got two remarks about this patch: - it seems that it does not take care about my patch. As I was to commit it today, I wonder if I still should do it. But then, your patch lacks some bugifxes (start_data not properly computed and TARGET_LONG_BITS != HOST_LONG_BITS problems). Well, I thought that you had already applied the patch. OK, do you agree that I apply it and you take the changes in yours ? Yes, the patch looks OK (haven't tested it) and if something still breaks, we can fix it. OK, as there were no other remarks, I will apply it now. - it seems that quite all the ELF loader code is affected by your patch. I think (maybe too naively) that adding functions to read the ELF infos should be sufficient, ie add a read_elf_ehdr, ..., functions and a few patches in the create_elf_table function. Then, all informations nedded to load a 32 bits executable can be kept into the 64 bits structures. As the kernel does not duplicate the code to handle this case, I think Qemu loader should be kept as simple as the kernel one, and the elfload_ops.h seems to me to be useless. In fact, Qemu loader could (should ?) even be the same code than the kernel one with just a few helpers for endianness swaps and the needed fixes to avoid confusions between host_long and target_long... Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which #includes fs/binfmt_elf.c. 64 bit V9 binaries are handled by fs/binfmt_elf.c. In Qemu we can't do it like this, because V9 instruction emulator must be used to handle also the 32 bit ELF. The same effect could be achieved in Qemu for example by adding new file elfload_32.c, which would include elfload.c after defining the ELF classes etc. This would need some rearranging in elfload.c so that the ELF parameters can be overridden. I'm not sure this would be much cleaner than my version using glue(). OK, then if the kernel duplicates the compiled code, it means that this way of doing might be the proper one. Couldn't you do something closest to what the kernel do, ie moving the per target definitions located at the top of elfload.c somewhere else and add a elfload_32.c file that would include elfload.c redefining all needed variable types, ... ? This just to keep the code as close as possible to the kernel one, even if it functionnaly changes nothing... I'll try if that works. It could be a better approach after all. OK, I think that would be great... -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/linux-user elfload.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 15:59:45 Modified files: linux-user : elfload.c Log message: Fix confusions between host and target long types. Fix start_data computation. Fix auxiliary infos setup. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.48r2=1.49
[Qemu-devel] qemu/linux-user main.c qemu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 16:06:13 Modified files: linux-user : main.c qemu.h Log message: Fix host and target longs confusions (continued). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.128r2=1.129 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.38r2=1.39
[Qemu-devel] qemu elf.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 16:07:25 Modified files: . : elf.h Log message: Report missing elf_addr_t definition from Linux kernel header CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/elf.h?cvsroot=qemur1=1.10r2=1.11
Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user
Blue Swirl wrote: [snip] Index: qemu/linux-user/qemu.h === --- qemu.orig/linux-user/qemu.h 2007-10-07 10:50:05.0 + +++ qemu/linux-user/qemu.h2007-10-07 10:51:09.0 + @@ -33,6 +33,7 @@ target_ulongdata_offset; char**host_argv; int personality; +int is_64bits; }; I think the 64bit-ness should be part of the personality. In the end, we need a notion of the ABI in use, not just a specific cpu feature flag. (MIPS Linux has working support for 4 ABIs, and it could be up to a dozen different variants counting the unimplemented bits.) Thiemo
[Qemu-devel] qemu hw/ppc.c target-ppc/cpu.h target-ppc/helpe...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 17:30:34 Modified files: hw : ppc.c target-ppc : cpu.h helper.c op.c op_mem.h translate.c Log message: PowerPC target coding style fixes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.31r2=1.32 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.75r2=1.76 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.71r2=1.72 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.54r2=1.55 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.89r2=1.90
[Qemu-devel] qemu/target-ppc cpu.h exec.h op_mem.h op_templa...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 18:19:26 Modified files: target-ppc : cpu.h exec.h op_mem.h op_template.h translate.c Log message: Implement PowerPC Altivec load stores, used by Apple firmware for memcpy. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.76r2=1.77 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemur1=1.27r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_template.h?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.90r2=1.91
Re: [Qemu-devel] PPC build errors in CVS
On Sun, 2007-10-07 at 17:06 -0400, Robert Reif wrote: PPC compiling has been broken for me in CVS for a few days and is getting worse. I'm running Red Hat 9. plain text document attachment (ppc.errors.txt) The current CVS builds here, at least on amd64 and x86. But Red Hat as a long tradition of buggy compilers, it seems... As I usually use gcc 3.4.6, I just tried with official gcc 4.1.1, 4.1.2 and 4.2.0 and it this file (target-ppc/translate.c) still compiles (with a lot of warnings though). I also took a look in C 99 specification and I saw no restriction on writing: do_this(a, #ifdef _this_is_defined b, #else c, #endif d); when do_this() is defined as a macro. May I suggest you to use a C99 compliant compiler ? I don't feel like making my code less readable just because some use buggy compilers. (but if someone tells me what in the ISO C specification, that I would have missed, explicitelly forbids this). [...] -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] PPC build errors in CVS
On Sun, Oct 07, 2007 at 11:45:51PM +0200, J. Mayer wrote: I also took a look in C 99 specification and I saw no restriction on writing: do_this(a, #ifdef _this_is_defined b, #else c, #endif d); when do_this() is defined as a macro. May I suggest you to use a C99 compliant compiler ? I don't feel like making my code less readable just because some use buggy compilers. (but if someone tells me what in the ISO C specification, that I would have missed, explicitelly forbids this). I'm pretty sure that it was either forbidden or unspecified, at least in C89. I didn't check C99. http://gcc.gnu.org/ml/gcc/1999-07n/msg00243.html ISO says in 6.8.3 (Macro replacement): If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined. GCC did not support it until here: http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01874.html -- Daniel Jacobowitz CodeSourcery
[Qemu-devel] qemu/target-ppc translate.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/07 23:10:08 Modified files: target-ppc : translate.c translate_init.c Log message: Work-around C89 and/or old gcc unspecified behavior (#if in macro calls). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.91r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.45r2=1.46
[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/08 02:23:00 Modified files: target-ppc : translate_init.c Log message: Add missing exception vectors for PowerPC 7x5. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.46r2=1.47
[Qemu-devel] qemu/target-ppc helper.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/08 02:35:41 Modified files: target-ppc : helper.c translate_init.c Log message: Implement exception prefix feature for PowerPC 601. Fix PowerPC 601 hardware reset vector. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.72r2=1.73 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.47r2=1.48
[Qemu-devel] qemu/target-ppc helper.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/08 02:44:11 Modified files: target-ppc : helper.c translate_init.c Log message: Real-mode only PowerPC 40x do not have any TLBs. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.73r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.48r2=1.49
[Qemu-devel] qemu/target-ppc cpu.h helper.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/08 02:58:07 Modified files: target-ppc : cpu.h helper.c translate_init.c Log message: Remove synonymous in PowerPC MSR bits definitions. Fix MSR EP bit buggy definition. Remove unuseful MSR flags. Fix MSR bits and flags definitions for most supported PowerPC implementations. Add MSR definitions/flags constistency checks and optional dump. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.77r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.74r2=1.75 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.49r2=1.50
