Re: [PATCH v2] Fix PR gdb/18653: gdb disturbs inferior's inherited signal dispositions

[Pedro Alves <palves@redhat.com>]

On 08/12/2016 09:21 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> +      else
>> +	{
>> +	  int m;
>> +
>> +	  fprintf (out, "sigaction={sa_handler=", i);
> 
> The redundant "i" causes a compilation warning,
> 
> gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args]
>     fprintf (out, "sigaction={sa_handler=", i);
>     ^
> 
> The patch blow fixes this.  With this patch applied, the test case can
> be compiled successfully.  

Thanks.  It's simply that v1 used it like this:

+      if (oldact.sa_handler == SIG_DFL)
+	fprintf (out, "%d: SIG_DFL\n", i);
+      else if (oldact.sa_handler == SIG_IGN)
+	fprintf (out, "%d: SIG_IGN\n", i);

and in v2 the signal number printing go split to a separate fprintf:

+      fprintf (out, "signal %d: ", i);

... I missed the 'i' that was left behind.

Please push.

> However test fails,
> 
> shell diff -s /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.base/signals-state-child/gdb.txt^M
> 13c13^M
> < signal 13: sigaction={sa_handler=SIG_DFL, sa_mask=0000000000000000000000000000000000000000000000000000000000000000, sa_flags=0}, masked=0^M
> ---^M
>> signal 13: sigaction={sa_handler=SIG_IGN, sa_mask=0000000000000000000000000000000000000000000000000000000000000000, sa_flags=0}, masked=0^M
> 25c25^M
> < signal 25: sigaction={sa_handler=SIG_DFL, sa_mask=0000000000000000000000000000000000000000000000000000000000000000, sa_flags=0}, masked=0^M
> ---^M
>> signal 25: sigaction={sa_handler=SIG_IGN, sa_mask=0000000000000000000000000000000000000000000000000000000000000000, sa_flags=0}, masked=0^M
> (gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
> 

First thing to check is whether running the standalone vs through-gdb check
outside dejagnu also shows differences. 

I realize now that NSIG is not the right upper bound, since it
doesn't cover the realtime signals.  Maybe it should be _NSIG if
available.  But that shouldn't explain this particular problem,
since NSIG is 32.

Thanks,
Pedro Alves