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
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).