[RFC/PATCH] New convenience variable $_exitsignal
Sergio Durigan Junior
sergiodj@redhat.com
Wed Jun 19 05:26:00 GMT 2013
On Monday, June 17 2013, I wrote:
> On Monday, June 17 2013, Pierre Muller wrote:
>
>> Hi Sergio,
>>
>> Is there a reason why you don't handle
>> corelow.c anymore in your new patch?
>
> Hi Pierre,
>
> Yes, corelow.c is not important to this patch because (as Pedro
> explained on
> <http://sourceware.org/ml/gdb-patches/2013-06/msg00337.html>)
> $_exitsignal should not be set for corefiles, because the inferior has
> not exited.
>
> corelow.c will be touched in my next patch, which will add $_signo (but
> with the modifications proposed by Pedro).
I've been thinking about this answer I gave to Pierre. After
investigating how corefiles handle the signal, I guess the right choice
would indeed be to set $_exitsignal in corelow.c as well. This is my
rationale.
1) Single-threaded program + generate-core-file
In this case, NT_SIGINFO will not be filled by GDB's generate-core-file
(bug) because PRSTATUS generation does not contemplate that yet (which
reminds me of the PRPSINFO work I did few months ago, and the PRSTATUS
work I still need to do, which will fix this bug). So, in this case,
"print $_siginfo.si_signo" will not display the correct signal, and we
can only rely on "bfd_core_file_failing_signal" (called inside
corelow.c). Thus, setting $_signo to "bfd_core_file_failing_signal" is
the logical choice (of course, if we want to avoid having to use
NT_SIGINFO, that is the *only* choice).
2) Single-threaded program + SIGSEGV (or another "Core" signal)
In this case, the Linux kernel correctly generates the NT_SIGINFO, which
can be displayed by $_siginfo. However, we don't want to use
NT_SIGINFO, so "bfd_core_file_failing_signal" is the only choice again.
3) Multi-threaded program + generate-core-file
Again, NT_SIGINFO is not generated by GDB. Again,
"bfd_core_file_failing_signal" is the only choice. (Back to this case
later)
4) Multi-threaded program + SIGSEGV (or another "Core" signal)
Linux kernel generated NT_SIGINFO, but we don't want to use it.
However, the kernel put in NT_SIGINFO the same signal number (which
killed the process) for all threads. Thus, using
"bfd_core_file_failing_signal" is OK since there is no concept of "this
signal number killed only this thread".
Case (3) is the most difficult IMO. I don't know how we are going to
handle it when I/we implement NT_SIGINFO generation on PRSTATUS. My
first reaction is to do it using the same logic as the Linux kernel,
i.e., putting the same signal number in every thread's siginfo. But I
don't think we should bikeshed too much now, so I'm stopping my e-mail
here.
I'd like to hear opinions.
Thanks,
--
Sergio
More information about the Gdb-patches
mailing list