This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Fix PR gdb/18653: gdb disturbs inferior's inherited signal dispositions
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