Jinoh Kang jinoh.kang.kr@gmail.com writes:
loader: Use long instead of int for syscall return type in i386 code.
I was planning to add more syscalls, and found that i386 code used "int" for syscall returns. My assumption was that it was a style issue (presumably 32-bit-area Wine's leftover) that I was expected to address _before_ I could add more inline asm blocks.
[The reason why I found "int" confusing was that I usually read "long" as "machine register-width integer," and "int" as "integer that either only needs to hold small values (e.g. exit code) _or_ has to be 32-bit for some reason." Granted int = long on ILP32, but someone looking at the code might not be able to immediately verify that the type is correct unless they also consider that "int $0x80" is for the i386 ABI (or that the code region is guarded by ifdef __i386__), and i386 is a 32-bit architecture. I supposed that would be extra cognitive load for someone reviewing/auditing the code.]
"long" doesn't mean pointer size in Win32, and since it differs between Win32 and Unix it's confusing, so we try to avoid it as much as possible. Here it's obviously safe, but that still makes it more confusing than "int", not less.
loader: Remove GCC <=4.x EBX register spilling workaround for i386.
Similar to above, but debugging related. Again I was adding asm blocks around, so I felt it obliged to fix it before adding more code.
I'm not convinced that this is safe, did you test on a really old gcc?
Meanwhile, following are patches that I deem necessary and not gratuitous:
loader: Refactor argv/envp/auxv management.
This was necessary because I had to pass around the pointers to stack objects a lot. Examples include getenv() for letting user control remapping behaviour via env vars, and stack relocation (which requires shifting all the argv/envp/auxv pointers). If the pointer variables were not in one place, the latter would make the code a lot hairy (by passing around all the scattered stack pointers) and unmaintainable.
Well, letting user control it through env vars is exactly what I mean with "unneeded infrastructure". No user is going to want to understand or tweak these things.
loader: Refactor number parsing to own function.
Number parsing was only for WINEPRELOADRESERVE. Now I need it for parsing /proc/self/maps as well.
You shouldn't need to parse /proc/self/maps at all.