Re: [PATCH] winegcc - do not create .exe.so
On 21 March 2011 15:47, Charles Davis wrote: > On 3/20/11 10:28 PM, Ben Klein wrote: >> On 21 March 2011 15:10, Charles Davis wrote: >>> On 3/20/11 9:31 PM, Ben Klein wrote: On 21 March 2011 12:26, Charles Davis wrote: > Also, as near as I can tell, this will only work on x86 Linux. It won't > work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is > because the 'start' code invokes execve(2) using the interrupt 80h > interface. Even if other systems use int 80h for their syscall vector > (Mac OS does, at least for Unix syscalls), the syscall numbers usually > aren't the same across different platforms. Does this also mean it will fail to work on amd64/ia64 systems? >>> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >>> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >>> keep the old int 80h interface around solely for the benefit of old >>> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >>> AJ fixed it) that expect it to be there. >>> >>> In fact, even if 64-bit code supported the int 80h interface, it still >>> wouldn't work, because even across different architectures on Linux, the >>> syscall numbers are different. >> >> Thanks for explaining it. >> >> Something else I noticed in this patch though; what happens to the >> environment variables handled by the loader script? > Nothing. He even hard-coded the path to the 'wine' binary (as a series > of DWORDs, no less!). I suspected that's what was going on. Basically, this patch makes absolutely no logical sense at all.
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 10:28 PM, Ben Klein wrote: > On 21 March 2011 15:10, Charles Davis wrote: >> On 3/20/11 9:31 PM, Ben Klein wrote: >>> On 21 March 2011 12:26, Charles Davis wrote: Also, as near as I can tell, this will only work on x86 Linux. It won't work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is because the 'start' code invokes execve(2) using the interrupt 80h interface. Even if other systems use int 80h for their syscall vector (Mac OS does, at least for Unix syscalls), the syscall numbers usually aren't the same across different platforms. >>> >>> Does this also mean it will fail to work on amd64/ia64 systems? >> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >> keep the old int 80h interface around solely for the benefit of old >> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >> AJ fixed it) that expect it to be there. >> >> In fact, even if 64-bit code supported the int 80h interface, it still >> wouldn't work, because even across different architectures on Linux, the >> syscall numbers are different. > > Thanks for explaining it. > > Something else I noticed in this patch though; what happens to the > environment variables handled by the loader script? Nothing. He even hard-coded the path to the 'wine' binary (as a series of DWORDs, no less!). Chip
Re: [PATCH] winegcc - do not create .exe.so
On 21 March 2011 15:10, Charles Davis wrote: > On 3/20/11 9:31 PM, Ben Klein wrote: >> On 21 March 2011 12:26, Charles Davis wrote: >>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>> because the 'start' code invokes execve(2) using the interrupt 80h >>> interface. Even if other systems use int 80h for their syscall vector >>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>> aren't the same across different platforms. >> >> Does this also mean it will fail to work on amd64/ia64 systems? > For 32-bit (x86) code running on an x86-64/IA64 system, it will work. > For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels > keep the old int 80h interface around solely for the benefit of old > 32-bit programs (like old versions of Wine, before Maarten Lankhorst and > AJ fixed it) that expect it to be there. > > In fact, even if 64-bit code supported the int 80h interface, it still > wouldn't work, because even across different architectures on Linux, the > syscall numbers are different. Thanks for explaining it. Something else I noticed in this patch though; what happens to the environment variables handled by the loader script?
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 9:31 PM, Ben Klein wrote: > On 21 March 2011 12:26, Charles Davis wrote: >> Also, as near as I can tell, this will only work on x86 Linux. It won't >> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >> because the 'start' code invokes execve(2) using the interrupt 80h >> interface. Even if other systems use int 80h for their syscall vector >> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >> aren't the same across different platforms. > > Does this also mean it will fail to work on amd64/ia64 systems? For 32-bit (x86) code running on an x86-64/IA64 system, it will work. For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels keep the old int 80h interface around solely for the benefit of old 32-bit programs (like old versions of Wine, before Maarten Lankhorst and AJ fixed it) that expect it to be there. In fact, even if 64-bit code supported the int 80h interface, it still wouldn't work, because even across different architectures on Linux, the syscall numbers are different. Chip
Re: [PATCH] winegcc - do not create .exe.so
On 21 March 2011 12:26, Charles Davis wrote: > Also, as near as I can tell, this will only work on x86 Linux. It won't > work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is > because the 'start' code invokes execve(2) using the interrupt 80h > interface. Even if other systems use int 80h for their syscall vector > (Mac OS does, at least for Unix syscalls), the syscall numbers usually > aren't the same across different platforms. Does this also mean it will fail to work on amd64/ia64 systems?
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 4:14 AM, Pali Rohár wrote: 2011/2/19 Pali Rohár: 2011/2/4 Pali Rohár: Hello, I created patch which implement correct _start section in ELF shared libraries/binaries which generate winegcc. Into _start section this patch add calling execve syscall which start wine with all arguments. So it is not needed to generate shell wrapper and .exe.so binary. This replace code on: http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so $ winegcc app.c --> generate only a.exe (shared object ELF binary), no aditional a.exe.so $ ./a.exe --> start binary correctly without shell wrapper -- Pali Rohár pali.ro...@gmail.com I rewrited my patch. Now set up correctly enviromental variables too. Assembler code is only for x86. -- Pali Rohár pali.ro...@gmail.com Can anybody review my patch? Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 6:54 PM, Chris Robinson wrote: > On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: >> On 03/20/2011 05:14 AM, Pali Rohár wrote: >>> Can anybody review my patch? >> >> Not sure what you trying to do exactly. Wine already has wrapper that makes >> all wine binaries executable after they are being installed into system. > > Wine installs wrapper scripts which call wine with the appropriate .exe.so > DSO. The .exe.so file can't be run directly. > > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the > .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. It's not enough to have a 'start' symbol. The binary has to be of the right type, too. On Mac OS, for example, the binary has to be of the MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or you won't be able to execve(2) it. With ELF, the binary type has to be ET_EXEC (instead of ET_DYN). Also, I don't know if Mac OS, Linux, or any other platform allows you to dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS, ET_DYN on ELF platforms). In that case, the right answer might just be to leave this alone. Another solution might be to re-implement the Wine loader logic in the executable itself, but I'm not sure if that's a good idea. Also, as near as I can tell, this will only work on x86 Linux. It won't work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is because the 'start' code invokes execve(2) using the interrupt 80h interface. Even if other systems use int 80h for their syscall vector (Mac OS does, at least for Unix syscalls), the syscall numbers usually aren't the same across different platforms. Chip
Re: [PATCH] winegcc - do not create .exe.so
On 03/20/2011 06:54 PM, Chris Robinson wrote: As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. This is what I understood as well. My problems with the patch are: - This should be platform independent and working everywhere Wine works - It should be optional at very minimum. It's not possible to run shared libraries for a reason. - Calling something .exe doesn't magically make it a PE-executable. You can't call ELF shared library a windows executable. File can stay .exe.so and still be executable as they are now Vitaliy.
Re: [PATCH] winegcc - do not create .exe.so
On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: > On 03/20/2011 05:14 AM, Pali Rohár wrote: > > Can anybody review my patch? > > Not sure what you trying to do exactly. Wine already has wrapper that makes > all wine binaries executable after they are being installed into system. Wine installs wrapper scripts which call wine with the appropriate .exe.so DSO. The .exe.so file can't be run directly. As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. This stuff isn't an area I'm familiar with, so I can't really comment on the patch itself.
Re: [PATCH] winegcc - do not create .exe.so
On 03/20/2011 05:14 AM, Pali Rohár wrote: Can anybody review my patch? Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.
Re: [PATCH] winegcc - do not create .exe.so
2011/2/4 Pali Rohár : > Hello, > > I created patch which implement correct _start section in ELF shared > libraries/binaries which generate winegcc. > Into _start section this patch add calling execve syscall which start > wine with all arguments. So it is not needed to generate shell wrapper > and .exe.so binary. > > This replace code on: > http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so > > $ winegcc app.c --> generate only a.exe (shared object ELF binary), no > aditional a.exe.so > $ ./a.exe --> start binary correctly without shell wrapper > > -- > Pali Rohár > pali.ro...@gmail.com > I rewrited my patch. Now set up correctly enviromental variables too. Assembler code is only for x86. -- Pali Rohár pali.ro...@gmail.com winegcc2.patch Description: Binary data
