Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

msys2-runtime-3.3 binaries no longer work #200

Closed
jeremyd2019 opened this issue Feb 19, 2024 · 3 comments · Fixed by #203
Closed

msys2-runtime-3.3 binaries no longer work #200

jeremyd2019 opened this issue Feb 19, 2024 · 3 comments · Fixed by #203

Comments

@jeremyd2019
Copy link
Member

From msys2/MSYS2-packages#4421, it was discovered that msys2-runtime-3.3-3.3.6-7 does not work, while -6 does, both on x86_64 and i686. On i686 at least, I found that downgrading to binutils-2.40-1 resulted in a working dll while any later version I tried did not.

Again on i686, I found that it crashed early on when the dll was loaded, in a memset call. It appears that the memory at _cygheap_start is not writable anymore.

@jeremyd2019
Copy link
Member Author

OK, check this out:

$ objdump -h /usr/bin/msys-2.0.dll

/usr/bin/msys-2.0.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
...
 11 .rsrc         00000408  612e6000  612e6000  002a6a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .cygheap      00209000  612e7000  612e7000  00000000  2**2
                  ALLOC

$ nm -B /usr/bin/msys-2.0.dll | grep cygheap_start
612e6408 D __cygheap_start
$ objdump -h usr/bin/msys-2.0.dll

usr/bin/msys-2.0.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
...
 11 .rsrc         00000408  612e5000  612e5000  002a6200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .cygheap      0020a000  612e6000  612e6000  00000000  2**2
                  ALLOC

$ nm -B usr/bin/msys-2.0.dll | grep cygheap_start
612e5408 R __cygheap_start

So _cygheap_start is actually in the .rsrc section, and that section seems to have changed to be READONLY. That actually makes some sense, due to:

.rsrc BLOCK(__section_alignment__) :
{
*(.rsrc)
*(SORT(.rsrc$*))
_SYM (_cygheap_start) = .;
}
.cygheap ALIGN(__section_alignment__) :
{
#ifdef __x86_64__
. = . + (3072 * 1024);
#else
. = . + (2048 * 1024);
#endif
. = ALIGN(0x10000);
_SYM (_cygheap_end) = .;
}

Maybe the solution is to figure out how to make the .rsrc section writable again? I have to imagine there's some good reason why _cygheap_start was put in the .rsrc instead of .cygheap section to begin with...

@lazka
Copy link
Member

lazka commented Feb 19, 2024

@jeremyd2019
Copy link
Member Author

I saw that, but I don't yet see a way to force the section to be writable. I've been playing with objcopy but I'm not getting --set-section-flags to do what I want.

jeremyd2019 added a commit to jeremyd2019/msys2-runtime that referenced this issue Feb 20, 2024
Binutils >= 2.41 started making .rsrc section read-only, which caused
memset(_cygheap_start, ...) to segfault.  Instead, put _cygheap_start in
the .cygheap section, which makes more sense anyway, but may result in
reducing the difference between _cygheap_start and _cygheap_end by the
fraction of a page not used in the .rsrc section.

Fixes msys2#200
See-also: https://cygwin.com/pipermail/cygwin/2024-February/255472.html
Signed-off-by: Jeremy Drake <github@jdrake.com>
@jeremyd2019 jeremyd2019 linked a pull request Feb 20, 2024 that will close this issue
lazka pushed a commit that referenced this issue Feb 23, 2024
Binutils >= 2.41 started making .rsrc section read-only, which caused
memset(_cygheap_start, ...) to segfault.  Instead, put _cygheap_start in
the .cygheap section, which makes more sense anyway, but may result in
reducing the difference between _cygheap_start and _cygheap_end by the
fraction of a page not used in the .rsrc section.

Fixes #200
See-also: https://cygwin.com/pipermail/cygwin/2024-February/255472.html
Signed-off-by: Jeremy Drake <github@jdrake.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants