This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED
- To: Nick Duffek <nsd at cygnus dot com>
- Subject: Re: RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED
- From: Stan Shebs <shebs at apple dot com>
- Date: Tue, 04 Apr 2000 13:16:53 -0800
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Core Tools, Apple Computer
- References: <200004030500.e33504n12192@rtl.cygnus.com>
- Reply-To: shebs at apple dot com
Nick Duffek wrote:
>
> The appended patch calls target_mourn_inferior() instead of target_kill()
> in response to TARGET_WAITKIND_SIGNALLED in handle_inferior_event().
>
> This comment precedes the target_kill():
>
> /* This looks pretty bogus to me. Doesn't TARGET_WAITKIND_SIGNALLED
> mean it is already dead? This has been here since GDB 2.8, so
> perhaps it means rms didn't understand unix waitstatuses?
> For the moment I'm just kludging around this in remote.c
> rather than trying to change it here --kingdon, 5 Dec 1994. */
>
> According to target.h, TARGET_WAITKIND_SIGNALLED does indeed mean that the
> program has terminated, and all current uses of TARGET_WAITKIND_SIGNALLED
> seem to honor that meaning. Here's where it gets used:
I've always wanted to understand that bit of code, but never got a
chance to really research it, so I don't have any additional info.
Given the antiquity of this bit, it's conceivable that some mid-80s
Unix flavor had a bug where processes weren't quite dead even
though reported as such, and target_kill was just an extra bullet
in the brain, just in case (how graphic).
Let's go with this change, but add a comment to the effect that
this used to be target_kill but nobody knew why, and maybe a bit of
the commentary that you included in your message, so that a future
hacker who discovers why target_kill is necessary won't be quite as
mystified as we are about why the code works as it does.
Stan