[PATCH v3 07/13] loader: Don't clobber existing memory mappings when reserving addresses.

[Alexandre Julliard]

Jinoh Kang <jinoh.kang.kr at 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.

-- 
Alexandre Julliard
julliard at winehq.org