Bug 1473411

Description of problem:
While trying to validate another bug (1468107) regarding whether a process was properly calling signal(SIGPIPE,SIG_IGN), I ran into a weird issue.  I was running the program under test inside gdb (in order to use a breakpoint at an opportune moment to make it easy to trigger SIGPIPE), and was able to get gdb to admit that SIGPIPE was indeed encountered on both my machine and the QE machine. But on my machine, the process died from SIGPIPE, while on the QE machine, the process ignored SIGPIPE, got EPIPE as its read() result, and exited normally.

I finally traced the difference: the QE machine was using an older version of gdb; and apparently, the older version leaks an ignored SIGPIPE to child processes, even when gdb itself was started with SIGPIPE at default status.

Version-Release number of selected component (if applicable):
qemu-img-1.5.3-140.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. First, prove that starting child processes indeed defaults to SIGPIPE at default status:
$ sleep 30&
$ grep SigIgn /proc/$!/status
$ kill %1

2. Next, note that gdb itself requests SIGPIPE to be ignored, but the real test is learning whether SIGPIPE is reverted back to default for the child process:
$ gdb --args sleep 30
(gdb) ! grep SigIgn /proc/self/status
(gdb) b main
(gdb) r
(gdb) info thread
(gdb) ! grep SigIgn /proc/XXX/status  # Fill in XXX based on the info thread results

Actual results:
1. For both machines I tested, I get:
$ sleep 30&
[1] 26872
$ grep SigIgn /proc/$!/status
SigIgn:	0000000000000000
$ kill %1
[1]+  Terminated              sleep 30

So I'm in an environment where children start life with SIGPIPE set to SIG_DFL.

2. On the QE machine, I saw:
$ gdb --args sleep 30
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
...
(gdb) ! grep SigIgn /proc/self/status
SigIgn:	0000000001001000
(gdb) b main
Breakpoint 1 at 0x401510
(gdb) r
Starting program: /usr/bin/sleep 30

Breakpoint 1, 0x0000000000401510 in main ()
(gdb) info thread
  Id   Target Id         Frame 
* 1    process 4885 "sleep" 0x0000000000401510 in main ()
(gdb) ! grep SigIgn /proc/4885/status
SigIgn:	0000000001001000
(gdb) 

Ouch - the child process is starting with SigIgn equal to gdb's environment.

Expected results:
On my working machine, I see:

GNU gdb (GDB) Fedora 8.0-13.fc26
...
(gdb) info thread
  Id   Target Id         Frame 
* 1    process 26798 "sleep" 0x0000555555555590 in main ()
(gdb) ! grep SigIgn /proc/26798/status
SigIgn:	0000000000000000


Additional info:
I didn't see anything in gdb 8's /usr/share/doc/gdb/NEWS that mentions that this was an intentional bug fix, but obviously newer gdb is being smarter about restoring the signals that it hands to the child process.  As it cost me some debug time to figure out why QE couldn't reproduce my test, it would be good to backport the fix to RHEL gdb.