x86_64-w64-mingw32-g++ -o helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native -I../../include /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld: helloworld.exe:.rdata_r: section below image base
clang + lld works but ld does not. Yes, it is the issue that relates to ld linker.
Nobody comes and fixes this?
Is that a mingw-w64 issue or libstdc++ issue? Or is it just because of the ld linker?
Hi cqwrteur, I am afraid that we are going to need some more information before we can get to the bottom of this issue. For example: * What is the code in helloworld.cc ? * Why is the "-s" option being used ? * Does the problem still occur if "-s" is not used ? * Similarly, does omitting "-flto" make the linking work ? It would help if you could upload the compiled form of helloworld.cc (ie helloworld.o). I did try to reproduce the problem myself, but the link worked. I was however using gcc version 11 not version 13. Also which version of the linker are you using ? Cheers Nick
Created attachment 14622 [details] C249694B8E474FF2AE570A876F184D45.png nope. none of them work. I can only make it work with lld. it does not work when the code dynamically linked with libstdc++ Probably it is the latest patch on GCC that changes the win32 thread model causes the issue. I am now using win32 thread model of GCC but libstdc++ cannot dynamically link. It works when -static-libstdc++ is used. My guess is that it might be either ld or libstdc++’s issues. From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> Sent: Tuesday, January 24, 2023 8:24:58 AM To: euloanty@live.com <euloanty@live.com> Subject: [Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows https://sourceware.org/bugzilla/show_bug.cgi?id=29973 Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nickc at redhat dot com --- Comment #4 from Nick Clifton <nickc at redhat dot com> --- Hi cqwrteur, I am afraid that we are going to need some more information before we can get to the bottom of this issue. For example: * What is the code in helloworld.cc ? * Why is the "-s" option being used ? * Does the problem still occur if "-s" is not used ? * Similarly, does omitting "-flto" make the linking work ? It would help if you could upload the compiled form of helloworld.cc (ie helloworld.o). I did try to reproduce the problem myself, but the link worked. I was however using gcc version 11 not version 13. Also which version of the linker are you using ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
(In reply to cqwrteur from comment #5) > Created attachment 14622 [details] > C249694B8E474FF2AE570A876F184D45.png > > nope. none of them work. I can only make it work with lld. > it does not work when the code dynamically linked with libstdc++ > Probably it is the latest patch on GCC that changes the win32 thread model > causes the issue. > > I am now using win32 thread model of GCC but libstdc++ cannot dynamically > link. > > It works when -static-libstdc++ is used. My guess is that it might be either > ld or libstdc++’s issues. > > > > From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> > Sent: Tuesday, January 24, 2023 8:24:58 AM > To: euloanty@live.com <euloanty@live.com> > Subject: [Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: > section below image base for windows > > https://sourceware.org/bugzilla/show_bug.cgi?id=29973 > > Nick Clifton <nickc at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |nickc at redhat dot com > > --- Comment #4 from Nick Clifton <nickc at redhat dot com> --- > Hi cqwrteur, > > I am afraid that we are going to need some more information before we can > get > to the bottom of this issue. For example: > > * What is the code in helloworld.cc ? > * Why is the "-s" option being used ? > * Does the problem still occur if "-s" is not used ? > * Similarly, does omitting "-flto" make the linking work ? > > It would help if you could upload the compiled form of helloworld.cc (ie > helloworld.o). I did try to reproduce the problem myself, but the link > worked. > I was however using gcc version 11 not version 13. > > Also which version of the linker are you using ? > > Cheers > Nick > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. Hi jwakely, I do not know whether it is an issue that relates to win32 thread model of libstdc++ or it is the issue with gnu ld. Can you investigate it for me? Thanks. cqwrteur@HOME-SERVER:~/Libraries/fast_io/examples/0001.helloworld$ x86_64-w64-mingw32-g++ -o helloworld helloworld.cc -Ofast -I../../include -std=c++23 -static-libstd c++ cqwrteur@HOME-SERVER:~/Libraries/fast_io/examples/0001.helloworld$ x86_64-w64-mingw32-g++ -o helloworld helloworld.cc -Ofast -I../../include -std=c++23 /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld: helloworld.exe:.rdata_r: section below image base
(In reply to cqwrteur from comment #6) > Hi jwakely, I do not know whether it is an issue that relates to win32 > thread model of libstdc++ or it is the issue with gnu ld. Can you > investigate it for me? Thanks. No.
(In reply to Jonathan Wakely from comment #7) > (In reply to cqwrteur from comment #6) > > Hi jwakely, I do not know whether it is an issue that relates to win32 > > thread model of libstdc++ or it is the issue with gnu ld. Can you > > investigate it for me? Thanks. > > No. What if it is libstdc++'s issue? I can statically link libstdc++ but I cannot do that dynamically. dynamically linking libgcc still works but libstdc++ does not.
(In reply to Jonathan Wakely from comment #7) > (In reply to cqwrteur from comment #6) > > Hi jwakely, I do not know whether it is an issue that relates to win32 > > thread model of libstdc++ or it is the issue with gnu ld. Can you > > investigate it for me? Thanks. > > No. yes
(In reply to Nick Clifton from comment #4) > Hi cqwrteur, > > I am afraid that we are going to need some more information before we can > get to the bottom of this issue. For example: > > * What is the code in helloworld.cc ? > * Why is the "-s" option being used ? > * Does the problem still occur if "-s" is not used ? > * Similarly, does omitting "-flto" make the linking work ? > > It would help if you could upload the compiled form of helloworld.cc (ie > helloworld.o). I did try to reproduce the problem myself, but the link > worked. I was however using gcc version 11 not version 13. > > Also which version of the linker are you using ? > > Cheers > Nick just any C++ code that would link to libstdc++ #include<iostream> int main() { std::cout<<"Hello World\n"; } For example remove -s -flto flags they all fail while -fuse-ld=lld would work.
Does the issue come from this patch? https://github.com/mirror/mingw-w64/commit/fc55e181b2d84c8817e3fd9d86c6944ac709acc9
(In reply to cqwrteur from comment #10) > just any C++ code that would link to libstdc++ > > #include<iostream> > > int main() > { > std::cout<<"Hello World\n"; > } > > For example > remove -s -flto flags they all fail while -fuse-ld=lld would work. I tried that, but the compilation and link still works for me. As I said though, I am using gcc 11 not gcc 13. (In reply to cqwrteur from comment #11) > Does the issue come from this patch? > > https://github.com/mirror/mingw-w64/commit/ > fc55e181b2d84c8817e3fd9d86c6944ac709acc9 It could do - I am not familiar with the mingw-w64 runtime code, so I cannot really say. If you have a workaound - using lld - then I would stick with that for now.
Created attachment 14626 [details] attachment-1763322-0.html lld does not work for canadian building compiler Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> Sent: Wednesday, January 25, 2023 8:37:38 AM To: euloanty@live.com <euloanty@live.com> Subject: [Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #12 from Nick Clifton <nickc at redhat dot com> --- (In reply to cqwrteur from comment #10) > just any C++ code that would link to libstdc++ > > #include<iostream> > > int main() > { > std::cout<<"Hello World\n"; > } > > For example > remove -s -flto flags they all fail while -fuse-ld=lld would work. I tried that, but the compilation and link still works for me. As I said though, I am using gcc 11 not gcc 13. (In reply to cqwrteur from comment #11) > Does the issue come from this patch? > > https://github.com/mirror/mingw-w64/commit/ > fc55e181b2d84c8817e3fd9d86c6944ac709acc9 It could do - I am not familiar with the mingw-w64 runtime code, so I cannot really say. If you have a workaound - using lld - then I would stick with that for now. -- You are receiving this mail because: You reported the bug. You are on the CC list for the bug.
Well I have just tried x86_64-w64-mingw32-g++ from Fedora rawhide (which is based on gcc version 12) and I still cannot reproduce the problem. So I am beginning to suspect that it is gcc version 13 specific. Are you using a home built version of x86_64-w64-mingw32, or have you downloaded it from somewhere ? Please could you create a helloworld.o object file and upload that ? Maybe with that I will be able to reproduce the problem.
Created attachment 14631 [details] attachment-1730064-0.html it is because of gcc 13 i guess. Old versions of mingw-w64 have the same issue. it is probably libstdc++'s problem since recently they made changes on adding C++ standard library threading support for win32 thread model Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> Sent: Thursday, January 26, 2023 7:38:27 AM To: euloanty@live.com <euloanty@live.com> Subject: [Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows https://sourceware.org/bugzilla/show_bug.cgi?id=29973 --- Comment #14 from Nick Clifton <nickc at redhat dot com> --- Well I have just tried x86_64-w64-mingw32-g++ from Fedora rawhide (which is based on gcc version 12) and I still cannot reproduce the problem. So I am beginning to suspect that it is gcc version 13 specific. Are you using a home built version of x86_64-w64-mingw32, or have you downloaded it from somewhere ? Please could you create a helloworld.o object file and upload that ? Maybe with that I will be able to reproduce the problem. -- You are receiving this mail because: You reported the bug. You are on the CC list for the bug.
Created attachment 14649 [details] libstdc++.dll.a I think the issue comes with libstdc++.dll.a but I am not sure. Can you have a look at libstdc++.dll.a?
(In reply to cqwrteur from comment #16) > I think the issue comes with libstdc++.dll.a but I am not sure. Can you have > a look at libstdc++.dll.a? Thank you - with those files I am now able to reproduce the problem. I have started investigating it ...
Created attachment 14652 [details] Proposed patch Interesting. The issue is the section itself: .rdata_r. This is not a normal PE section name, and it is missing from the default script used by the linker. So instead the orphan section handling code is activated, and this places the section into the .rdata section. But in doing so, it also sets the vaddr for the .rdata section to 0. The .rdata_r section is being created by the LTO plugin when it recompiles helloworld.cc. I am not sure why this is happening. But there is an easy fix - add the .rdata_r section to the default linker map. So that is what this patch does. Please try out the patch and let me know if it works for you.
(In reply to Nick Clifton from comment #18) > Created attachment 14652 [details] > Proposed patch > > Interesting. The issue is the section itself: .rdata_r. This is not a > normal PE section name, and it is missing from the default script used by > the linker. So instead the orphan section handling code is activated, and > this places the section into the .rdata section. But in doing so, it also > sets the vaddr for the .rdata section to 0. > > The .rdata_r section is being created by the LTO plugin when it recompiles > helloworld.cc. I am not sure why this is happening. But there is an easy > fix - add the .rdata_r section to the default linker map. So that is what > this patch does. > > Please try out the patch and let me know if it works for you. thank you it is working now.
(In reply to Nick Clifton from comment #18) > Created attachment 14652 [details] > Proposed patch > > Interesting. The issue is the section itself: .rdata_r. This is not a > normal PE section name, and it is missing from the default script used by > the linker. So instead the orphan section handling code is activated, and > this places the section into the .rdata section. But in doing so, it also > sets the vaddr for the .rdata section to 0. > > The .rdata_r section is being created by the LTO plugin when it recompiles > helloworld.cc. I am not sure why this is happening. But there is an easy > fix - add the .rdata_r section to the default linker map. So that is what > this patch does. > > Please try out the patch and let me know if it works for you. Please merge the patch. It is important for me
(In reply to cqwrteur from comment #20) > (In reply to Nick Clifton from comment #18) > > Created attachment 14652 [details] > > Proposed patch > > > > Interesting. The issue is the section itself: .rdata_r. This is not a > > normal PE section name, and it is missing from the default script used by > > the linker. So instead the orphan section handling code is activated, and > > this places the section into the .rdata section. But in doing so, it also > > sets the vaddr for the .rdata section to 0. > > > > The .rdata_r section is being created by the LTO plugin when it recompiles > > helloworld.cc. I am not sure why this is happening. But there is an easy > > fix - add the .rdata_r section to the default linker map. So that is what > > this patch does. > > > > Please try out the patch and let me know if it works for you. > > Please merge the patch. It is important for me The code compiles but it crashes for dynamically linking libstdc++-6.dll
(In reply to cqwrteur from comment #21) > (In reply to cqwrteur from comment #20) > > (In reply to Nick Clifton from comment #18) > > > Created attachment 14652 [details] > > > Proposed patch > > > > > > Interesting. The issue is the section itself: .rdata_r. This is not a > > > normal PE section name, and it is missing from the default script used by > > > the linker. So instead the orphan section handling code is activated, and > > > this places the section into the .rdata section. But in doing so, it also > > > sets the vaddr for the .rdata section to 0. > > > > > > The .rdata_r section is being created by the LTO plugin when it recompiles > > > helloworld.cc. I am not sure why this is happening. But there is an easy > > > fix - add the .rdata_r section to the default linker map. So that is what > > > this patch does. > > > > > > Please try out the patch and let me know if it works for you. > > > > Please merge the patch. It is important for me > > The code compiles but it crashes for dynamically linking libstdc++-6.dll #include<iostream> int main() { std::cout<<"Hello World\n"; } cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ x86_64-w64-mingw32-g++ -o iostream iostream.cc -Ofast -std=c++23 cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ wine ./iostream.exe wine: Unhandled page fault on read access to 00000004FEAABE98 at address 00000003BE9ED6CD (thread 00d8), starting debugger... Unhandled exception: page fault on read access to 0x4feaabe98 in 64-bit code (0x000 00003be9ed6cd). .... ignore x86_64-w64-mingw32-g++ -o iostream iostream.cc -Ofast -std=c++23 -fuse-ld=lld cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ ./iostream.exe ^C cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ wine ./iostream.exe Hello World
(In reply to cqwrteur from comment #22) > (In reply to cqwrteur from comment #21) > > (In reply to cqwrteur from comment #20) > > > (In reply to Nick Clifton from comment #18) > > > > Created attachment 14652 [details] > > > > Proposed patch > > > > > > > > Interesting. The issue is the section itself: .rdata_r. This is not a > > > > normal PE section name, and it is missing from the default script used by > > > > the linker. So instead the orphan section handling code is activated, and > > > > this places the section into the .rdata section. But in doing so, it also > > > > sets the vaddr for the .rdata section to 0. > > > > > > > > The .rdata_r section is being created by the LTO plugin when it recompiles > > > > helloworld.cc. I am not sure why this is happening. But there is an easy > > > > fix - add the .rdata_r section to the default linker map. So that is what > > > > this patch does. > > > > > > > > Please try out the patch and let me know if it works for you. > > > > > > Please merge the patch. It is important for me > > > > The code compiles but it crashes for dynamically linking libstdc++-6.dll > > #include<iostream> > > int main() > { > std::cout<<"Hello World\n"; > } > > cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ x86_64-w64-mingw32-g++ -o > iostream iostream.cc -Ofast -std=c++23 > cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ wine ./iostream.exe > wine: Unhandled page fault on read access to 00000004FEAABE98 at address > 00000003BE9ED6CD (thread 00d8), starting debugger... > Unhandled exception: page fault on read access to 0x4feaabe98 in 64-bit code > (0x000 > 00003be9ed6cd). > .... ignore > > x86_64-w64-mingw32-g++ -o iostream iostream.cc -Ofast -std=c++23 -fuse-ld=lld > cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ ./iostream.exe ^C > cqwrteur@HOME-SERVER:~/Libraries/fast_io/.tmp$ wine ./iostream.exe > Hello World The ld linker is still buggy.
Created attachment 14656 [details] Proposed patch Hi, Oops - I forgot about section names containing the $ character. Please could you try out this revised patch and let me know if it works properly this time. Cheers Nick
(In reply to Nick Clifton from comment #24) > Created attachment 14656 [details] > Proposed patch > > Hi, > > Oops - I forgot about section names containing the $ character. > > Please could you try out this revised patch and let me know if it works > properly this time. > > Cheers > Nick looks like it is working now. However, I will try to build CMake to try whether it works out.
(In reply to cqwrteur from comment #25) > (In reply to Nick Clifton from comment #24) > > Created attachment 14656 [details] > > Proposed patch > > > > Hi, > > > > Oops - I forgot about section names containing the $ character. > > > > Please could you try out this revised patch and let me know if it works > > properly this time. > > > > Cheers > > Nick > > looks like it is working now. However, I will try to build CMake to try > whether it works out. cqwrteur@HOME-SERVER:~/Temp$ wine ./iostream.exe wine: Unhandled page fault on read access to 00000004FEAABEB0 at address 00000003BE9ED6CD (thread 00ec), starting debugger... Unhandled exception: page fault on read access to 0x4feaabeb0 in 64-bit code (0x000 00003be9ed6cd). Register dump: No it is still not working for iostream
Created attachment 14659 [details] iostream
(In reply to Nick Clifton from comment #24) > Created attachment 14656 [details] > Proposed patch > > Hi, > > Oops - I forgot about section names containing the $ character. > > Please could you try out this revised patch and let me know if it works > properly this time. > > Cheers > Nick Hello can you further investigate the issue here?
Created attachment 14666 [details] This is my build script
(In reply to Nick Clifton from comment #24) > Created attachment 14656 [details] > Proposed patch > > Hi, > > Oops - I forgot about section names containing the $ character. > > Please could you try out this revised patch and let me know if it works > properly this time. > > Cheers > Nick Hello. Could you fix it? Since the bug makes it impossible to use gcc on windows.
I am investigating. But without any way to run newly linked executables, finding out what is wrong is proving to be quite difficult.
Hi, I am wondering if there are two problems here, rather than just one. So please could you check a couple of things for me ? 1. Does iostream.exe fail to run if built without LTO ? 2. Where does iostream.exe fail ? Is it before main(), or when the libstdc++ library is being loaded, or somewhere else ? Thanks Nick
(In reply to Nick Clifton from comment #32) > Hi, > > I am wondering if there are two problems here, rather than just one. So > please could you check a couple of things for me ? > > 1. Does iostream.exe fail to run if built without LTO ? > 2. Where does iostream.exe fail ? Is it before main(), or when the > libstdc++ library is being loaded, or somewhere else ? > > Thanks > Nick it fails to run without lto. yes when libstdc++ library is being loaded.
(In reply to cqwrteur from comment #33) > (In reply to Nick Clifton from comment #32) > > Hi, > > > > I am wondering if there are two problems here, rather than just one. So > > please could you check a couple of things for me ? > > > > 1. Does iostream.exe fail to run if built without LTO ? > > 2. Where does iostream.exe fail ? Is it before main(), or when the > > libstdc++ library is being loaded, or somewhere else ? > > > > Thanks > > Nick > > it fails to run without lto. yes > > when libstdc++ library is being loaded. if it is -static-libstdc++ then it works. Or it just crashes the program. I tried with lld and it works even with GCC or clang with/without lto.
(In reply to Nick Clifton from comment #32) > Hi, > > I am wondering if there are two problems here, rather than just one. So > please could you check a couple of things for me ? > > 1. Does iostream.exe fail to run if built without LTO ? > 2. Where does iostream.exe fail ? Is it before main(), or when the > libstdc++ library is being loaded, or somewhere else ? > > Thanks > Nick I have tried. Looks like this issue only happens when iostream is included since iostream has a static global variable that causes issues. https://github.com/gcc-mirror/gcc/blob/07f497c2da3600cc99cd7d1b5c6726972fb2b5a1/libstdc%2B%2B-v3/include/std/iostream#L78 https://github.com/gcc-mirror/gcc/blob/ec59848074ba8c4310cbadb603822bfaeff03a32/libstdc%2B%2B-v3/src/c%2B%2B98/ios_base_init.h #if __has_attribute(init_priority) static ios_base::Init __ioinit __attribute__((init_priority(90))); #endif It has this new init_priority attribute. Perhaps ld fails to understand PE targets while lld does?
https://github.com/gcc-mirror/gcc/commit/ec59848074ba8c4310cbadb603822bfaeff03a32 See this
jwakely do you think it is caused by __init_priority__ ?
(In reply to Nick Clifton from comment #32) > Hi, > > I am wondering if there are two problems here, rather than just one. So > please could you check a couple of things for me ? > > 1. Does iostream.exe fail to run if built without LTO ? > 2. Where does iostream.exe fail ? Is it before main(), or when the > libstdc++ library is being loaded, or somewhere else ? > > Thanks > Nick https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108918
(In reply to Nick Clifton from comment #14) > Well I have just tried x86_64-w64-mingw32-g++ from Fedora rawhide (which is > based on gcc version 12) and I still cannot reproduce the problem. So I am > beginning to suspect that it is gcc version 13 specific. > > Are you using a home built version of x86_64-w64-mingw32, or have you > downloaded it from somewhere ? > > Please could you create a helloworld.o object file and upload that ? Maybe > with that I will be able to reproduce the problem. As March has already begun, it would be appreciated if the bug for binutils-gdb could be resolved as soon as possible before the official release in April.
(In reply to Nick Clifton from comment #32) > Hi, > > I am wondering if there are two problems here, rather than just one. So > please could you check a couple of things for me ? > > 1. Does iostream.exe fail to run if built without LTO ? > 2. Where does iostream.exe fail ? Is it before main(), or when the > libstdc++ library is being loaded, or somewhere else ? > > Thanks > Nick Still crashes today. Please fix this asap.
move for issue 30254
*** Bug 30375 has been marked as a duplicate of this bug. ***