public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug lto/109368] New: LTO drops entry point symbol @ 2023-04-01 10:17 pali at kernel dot org 2023-04-01 11:53 ` [Bug lto/109368] " pinskia at gcc dot gnu.org ` (4 more replies) 0 siblings, 5 replies; 6+ messages in thread From: pali at kernel dot org @ 2023-04-01 10:17 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 Bug ID: 109368 Summary: LTO drops entry point symbol Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: pali at kernel dot org CC: marxin at gcc dot gnu.org Target Milestone: --- Target: Mingw32 LTO for PE executables drops entry point symbol when the default entry point is used. There is no warning and just PE AddressOfEntryPoint is zeroed. Which results in broken PE binary. When non-default entry point is used and specified via -e option then LTO does not drop entry point symbol and generates working PE executable. Simple test case which does not use any system library or startup file: $ cat test-nostartfiles.c int mainCRTStartup(void) { return 0; } Default console binary has entry point mainCRTStartup() function (as hardcoded in LD sources). $ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib test-nostartfiles.c -o test-nostartfiles.exe Without LTO it generates working PE binary which correctly returns 0 to system. It also has correct AddressOfEntryPoint field in PE: $ i686-w64-mingw32-objdump -p test-nostartfiles.exe | grep AddressOfEntryPoint AddressOfEntryPoint 00001000 When compiling with LTO it does not throw any warning but generates broken PE binary: $ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib test-nostartfiles.c -o test-nostartfiles.exe -flto Trying to run it, it crashes and has zeroed AddressOfEntryPoint: $ i686-w64-mingw32-objdump -p test-nostartfiles.exe | grep AddressOfEntryPoint AddressOfEntryPoint 00000000 When non-default entry point is used (specified via -e option) then LTO works correctly and does not drop its entry point. $ cat test-nostartfiles2.c int my_entry(void) { return 0; } $ i686-w64-mingw32-gcc -Wall -Wextra -nostartfiles -nodefaultlibs -nostdlib -e _my_entry test-nostartfiles2.c -o test-nostartfiles2.exe -flto $ i686-w64-mingw32-objdump -p test-nostartfiles2.exe | grep AddressOfEntryPoint AddressOfEntryPoint 00001000 Compiled binary works fine. So there is a bug in LTO compiler that it drops entry point if default one is used (i.e. when entry point is not specified via -e option). ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/109368] LTO drops entry point symbol 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org @ 2023-04-01 11:53 ` pinskia at gcc dot gnu.org 2023-04-01 11:55 ` pali at kernel dot org ` (3 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2023-04-01 11:53 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Are you sure this is a GCC issue rather than a binutils issue? ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/109368] LTO drops entry point symbol 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org 2023-04-01 11:53 ` [Bug lto/109368] " pinskia at gcc dot gnu.org @ 2023-04-01 11:55 ` pali at kernel dot org 2023-04-01 12:13 ` amonakov at gcc dot gnu.org ` (2 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: pali at kernel dot org @ 2023-04-01 11:55 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 --- Comment #2 from Pali Rohár <pali at kernel dot org> --- I do not know. The issue happens when LTO is enabled for GCC. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/109368] LTO drops entry point symbol 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org 2023-04-01 11:53 ` [Bug lto/109368] " pinskia at gcc dot gnu.org 2023-04-01 11:55 ` pali at kernel dot org @ 2023-04-01 12:13 ` amonakov at gcc dot gnu.org 2023-04-01 12:21 ` pali at kernel dot org 2023-04-01 12:44 ` xry111 at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: amonakov at gcc dot gnu.org @ 2023-04-01 12:13 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 Alexander Monakov <amonakov at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov <amonakov at gcc dot gnu.org> --- This is a Binutils bug. GCC does not have any special knowledge that mainCRTStartup needs to be preserved (depending on targeted Windows subsystem), it just preserves the symbols the linker tells it to preserve. You can see how the linker selects the default entry point for PE targets: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=2a3fd0e6ea802b3683dc786540d13b92f92e9160;hb=HEAD#l572 Perhaps the selection happens too late, even though there's a specific attempt to take it into account: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldlang.c;h=b684e2d479acf18f58076a3b5c78627caa6d8e4f;hb=HEAD#l8082 (if you inspect GCC dumps produced with -fdump-ipa-all, you'll see that mainCRTStartup is marked as prevailing_def_ironly instead of prevailing_def) Would you mind reporting it to the Binutils bugzilla and leaving a link to the new bug here? ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/109368] LTO drops entry point symbol 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org ` (2 preceding siblings ...) 2023-04-01 12:13 ` amonakov at gcc dot gnu.org @ 2023-04-01 12:21 ` pali at kernel dot org 2023-04-01 12:44 ` xry111 at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: pali at kernel dot org @ 2023-04-01 12:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 --- Comment #4 from Pali Rohár <pali at kernel dot org> --- Reported to binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=30300 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/109368] LTO drops entry point symbol 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org ` (3 preceding siblings ...) 2023-04-01 12:21 ` pali at kernel dot org @ 2023-04-01 12:44 ` xry111 at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: xry111 at gcc dot gnu.org @ 2023-04-01 12:44 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368 Xi Ruoyao <xry111 at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED URL| |https://sourceware.org/bugz | |illa/show_bug.cgi?id=30300 --- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- Mark as moved then. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-01 12:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-01 10:17 [Bug lto/109368] New: LTO drops entry point symbol pali at kernel dot org 2023-04-01 11:53 ` [Bug lto/109368] " pinskia at gcc dot gnu.org 2023-04-01 11:55 ` pali at kernel dot org 2023-04-01 12:13 ` amonakov at gcc dot gnu.org 2023-04-01 12:21 ` pali at kernel dot org 2023-04-01 12:44 ` xry111 at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).