On Sun Jun 22 16:00:20 2025 +0000, Jinoh Kang wrote:
First of all, welcome to WineHQ and thanks for your contribution! By "doesn't define a specific order" I assume you're referring to this paragraph:
Argument strings, environment strings, and the auxiliary information
appear in no spe- cific order within the information block and they need not be compactly allocated.[^1] However, the *de facto* Linux ABI guarantees that the argument strings are, in fact, in the argv[] order. Why? On Linux, the information block page is shared with the kernel. When you modify argv strings, it is reflected in `/proc/<PID>/cmdline` so that tools like `top` and `htop` can inspect them. `cmdline` is a simple concatenation of argv strings delimited with NULL characters, and it always starts with argv[0]. The initial stack follows the same layout. The emulator is *not* respecting this layout guarantee. So, the emulator is broken. The emulator needs to be fixed if it wants to run *Linux* programs, not just SysV ABI-compliant ones. Hopefully it accepts contributions? Note that this patch doesn't work on the (broken) emulator either: it crashes *with or without* the assertion. [^1]: H.J. Lu et al., *System V Application Binary Interface AMD64 Architecture Processor Supplement (With LP64 and ILP32 Programming Models), Version 1.0.* §3.4.1 "Initial Stack and Register State," March 12, 2025.
You are correct, in that a proper emulator should push these arguments to the information block in the same order as the Linux kernel. It is also the case that most programs don't actually rely on the order that the things in the information blocks are pushed.
The intention of this patch isn't to change this reliance. That's completely fine. It is an assert for future emulator developers that might land on this issue to save them a bit of debugging time.
Yes, the emulator would be broken if it doesn't push them in the correct order. It has been fixed in my case. Personally it took me an hour or two to figure out what I was doing wrong, so I thought why not commit an assert in wine for anyone that might run into the same problem in the future?
PS. If you think this is not something the wine project should care about, then I am fine with closing this merge request.