public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "lh_mouse at 126 dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug other/105335] New: libiberty does not handle script exit codes correctly. Date: Thu, 21 Apr 2022 14:36:48 +0000 [thread overview] Message-ID: <bug-105335-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 Bug ID: 105335 Summary: libiberty does not handle script exit codes correctly. Product: gcc Version: 11.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 52847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52847&action=edit proposed patch A few days ago I was playing with linker plugins. I created a bug in the LTO plugin that it segfaulted when the process was about to terminate. While I was attempt to bootstrap GCC with this modified piece of code, it failed during stage1 with a mysterious message: ``` configure:3566: /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./gcc/xgcc -B/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./gcc/ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/x86_64-w64-mingw32/sys-include -fno-checking -o conftest -g -march=x86-64 -mtune=generic -O2 -pipe -pipe conftest.c >&5 C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc_eh: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc_eh: No such file or directory configure:3669: error: C compiler cannot create executables ``` Later I found that it was because configure couldn't tell whether the stage1 compiler should fail, as it always returned zero, indicating success. But how? Apparently ld failed with errors, and GCC should not have exited with zero. I used GDB to dig for a while. There didn't seem anything wrong with GCC. It was collect2 that returned zero. collect2 seemed to invoke ld indirectly, so I set a breakpoint on `GetExitCodeProcess()`. This of course got the exit code of ld (I thought so, but it was wrong! see below), which was 2816, so it failed, but in liberty `pex_win32_wait()` took merely its lowest byte and consider it the exit status, which was zero, which was incorrect. Later I set a breakpoint on `CreateProcessA()` and realized the aforementioned process that exited with 2816 was actually created by `spawn_script()`, which attempted to parse the shebang of `collect-ld`, which should denote `/bin/sh`. I had a working MSYS2 shell at the moment, and it correctly detected the segfault and returned 2816 = (11 << 8), indicating the signal 11 = SIGSEGV. So far we can conclude that there is a bug in libiberty: It only takes the lowest byte as the child process's exit status. If the child (bash) fails with 2816 then it is mistaken as having exited successfully. Untested patch attached.
next reply other threads:[~2022-04-21 14:36 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-21 14:36 lh_mouse at 126 dot com [this message] 2022-04-21 16:32 ` [Bug other/105335] " pinskia at gcc dot gnu.org 2022-04-22 6:06 ` rguenth at gcc dot gnu.org 2022-04-22 6:54 ` lh_mouse at 126 dot com 2022-04-23 22:28 ` ebotcazou at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-105335-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).