mstorsjo
Using -align with lld and SectionAlignment field in the COFF header
Hi @mstorsjo long time no see, hope you are keeping well :) I've been playing with having wine work on a 16k page size arm host mainly on apple MacOS and Asahi Linux.
[martell@martell-mac ~]$ cat main.c
int main() { return 0; }
[martell@martell-mac ~]$ aarch64-w64-mingw32-gcc main.c -Wl,-section-alignment=16384
ld.lld: warning: /align specified without /driver; image may not run
[martell@martell-mac ~]$ llvm-objdump -p main.exe | grep SectionAlignment
SectionAlignment 00001000
I somewhat expected the -section-alignment flag to set the COFF header for SectionAlignment to 0x4000 There could be something else going on which is why I said i would ask you here first before I start writing a patch. I see the mingw driver setting the flag -align in the link driver but I also see the default in Config.h as 0x1000
Hi @mstorsjo long time no see, hope you are keeping well :)
Indeed, long time no see!
I've been playing with having wine work on a 16k page size arm host mainly on apple MacOS and Asahi Linux.
Ah, nice! I played with this back in 2020, https://www.winehq.org/pipermail/wine-devel/2020-August/171857.html, but haven't done much about it since.
On Asahi Linux, wouldn't the default be 4k pages, otherwise random binaries couldn't be executed there either? Or is the situation different there?
[martell@martell-mac ~]$ cat main.c int main() { return 0; } [martell@martell-mac ~]$ aarch64-w64-mingw32-gcc main.c -Wl,-section-alignment=16384 ld.lld: warning: /align specified without /driver; image may not run [martell@martell-mac ~]$ llvm-objdump -p main.exe | grep SectionAlignment SectionAlignment 00001000I somewhat expected the -section-alignment flag to set the COFF header for SectionAlignment to 0x4000 There could be something else going on which is why I said i would ask you here first before I start writing a patch. I see the mingw driver setting the flag -align in the link driver but I also see the default in Config.h as 0x1000
Yes, that's how it's supposed to work. I tried the option now, and it seems to work fine for me (note, the canonical spelling for the option is with two leading dashes; the GNU style linker interface uses a single dash for single char options, and double dashes for long options).
In your example, aarch64-w64-mingw32-gcc main.c without an explicit -o will produce an executable called a.exe, while main.exe probably is an old one. By repeating your commands but inspecting a.exe I do find the right alignment.
Yes, that's how it's supposed to work. I tried the option now, and it seems to work fine for me (note, the canonical spelling for the option is with two leading dashes; the GNU style linker interface uses a single dash for single char options, and double dashes for long options). In your example, aarch64-w64-mingw32-gcc main.c without an explicit -o will produce an executable called a.exe, while main.exe probably is an old one. By repeating your commands but inspecting a.exe I do find the right alignment.
I realized after I posted the question, I should have went to bed earlier haha I'm a little rusty, thanks for pointing that out.
Ah, nice! I played with this back in 2020, https://www.winehq.org/pipermail/wine-devel/2020-August/171857.html, but haven't done much about it since.
Ohh no I just spent last 2 weekends re-implementing a lot of this work. A google search did not turn up your patches. I'm still glad I asked now.
On Asahi Linux, wouldn't the default be 4k pages, otherwise random binaries couldn't be executed there either? Or is the situation different there?
Their Kernel is 16k page only, https://github.com/AsahiLinux/docs/wiki/Broken-Software though the cpu itself does support 4k so I could just rebuild it. It seems that Box64 is still able to run x64 binaries which definitely have a smaller Page Size. Some magic happened there https://box86.org/2022/03/box64-running-on-m1-with-asahi/
I'm mainly just trying to test nine support on asahi and need to build and run some aarch64 d3d windows executables for testing it. https://gitlab.freedesktop.org/asahi/mesa/-/merge_requests/202
Seems we are here. A question I do have is if I say build a windows executable with a 16k section size that will still work on a 4k Kernel ? I'm wondering if I could make wine just build 64k by default for aarch64 and it will work on all the different kernel page size configurations.
On Asahi Linux, wouldn't the default be 4k pages, otherwise random binaries couldn't be executed there either? Or is the situation different there?
Their Kernel is 16k page only, https://github.com/AsahiLinux/docs/wiki/Broken-Software though the cpu itself does support 4k so I could just rebuild it. It seems that Box64 is still able to run x64 binaries which definitely have a smaller Page Size. Some magic happened there https://box86.org/2022/03/box64-running-on-m1-with-asahi/
Hmm, I read somewhere that regular Linux/ELF binaries for aarch64 commonly are linked with 64k pages, since aarch64 can be configured with either 4k, 16k or 64k pages. So that would explain why there's no issue there.
Seems we are here. A question I do have is if I say build a windows executable with a 16k section size that will still work on a 4k Kernel ? I'm wondering if I could make wine just build 64k by default for aarch64 and it will work on all the different kernel page size configurations.
A windows executable with a 16k section alignment runs fine on regular Windows as well; any alignment larger than the system one should be fine.