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
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().
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.
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
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
