When a subprocess (say, lto1) gets killed by SIGKILL on Linux with
LANG=en_..., the message GCC prints is "Killed signal terminated program
lto1".
This message is a little bit unclear - the "Killed" is certainly not
something that gramatically fits there, and the syscall for sending a
signal is called "kill", so the above sounds like an incorrect way of
saying "program lto1 was killed by some signal".
I can't find any decent description of what the correct class of words
strsignal returns, so, lets instead print "PROG killed by signal
9 (Killed)". This is clearer; it states that signal 9 is at fault and
gives the OS-provided "descriptive string" corresponding to that signal.
Example:
~/gcc/_b_gcc/gcc$ ./xgcc -B. -x c -
xgcc: fatal error: cc1 killed by signal 9 (Killed)
compilation terminated.
~/gcc/_b_gcc/gcc 1 $
gcc/ChangeLog:
* gcc.cc (execute): Make "signal terminated program" message
clearer.
Suggested-by: Alexander Monakov <[email protected]>
---
Tested on x86_64-linux-gnu, including by running the test xgcc command
above and SIGKILL-ing cc1. OK for trunk?
gcc/gcc.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index b8b0db4ed5e4..a0afb38cdc9a 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -3563,7 +3563,9 @@ execute (void)
thinking there's a compiler bug. Much more likely is
the user or OOM killer nuked it. */
fatal_error (input_location,
- "%s signal terminated program %s",
+ "%s terminated by signal %d (%s)",
+ commands[i].prog,
+ WTERMSIG (status),
strsignal (WTERMSIG (status)),
commands[i].prog);
break;
--
2.55.0
