Re: [RFA] Don't kill inferior if there's a typo in the specified port.

[Doug Evans <dje@google.com>]

On Sat, Apr 11, 2009 at 8:04 AM, Pedro Alves <pedro@codesourcery.com> wrote:
>> It also moves the status message to the callback;
>> it's only called when exiting gdb (and if that changes one can split
>> the function into silent/verbose versions).
>> An alternative is something like this:
>>
>> -      fprintf (stderr, "Killing all inferiors\n");
>> +      fprintf (stderr, "Detaching or killing all inferiors\n");
>>
>> but will that be confusing?
>
> Perhaps:
>
>  "Detaching from inferiors we had attached to, and killing all others\n"
>
> dunno, don't want to start a bikeshed-ish discussion on that.
>
>> OTOH, if gdbserver ever gets used with 10's or 100's of processes,
>> exiting with one line per process may be a bit much.
>> OTOOH, the user might like to know what got detached and what got killed.
>> I don't know, but I can change the patch to do whatever y'all prefer.
>
> Yeah.  If this is a real problem, then we could output something like,
>
>  Killing process(es) PID1, PID2, PID3, PID4, PIDnn.
>  Detaching process(es) PID1, PID2, PID3, PID4, PIDnn.
>
> This should mitigate the problem, although if you're really attached to
> 100's of processes, it will still print a lot.
>
> The other thing that crossed my mind was that if you had a bunch
> of processes, the real error message that let to gdbserver bailing out
> would be buried in the output many lines before all those
> "Killing/detaching process X".  The only version that doesn't
> have this problem is the one that doesn't include any detail, like
> the first option.

One reason why I like printing which processes were detached from and
which were killed is: What happens if the process is gone shortly
after gdbserver exits?  Did gdbserver kill it, or did the detach screw
up, or did the program crash on its own shortly after gdbserver
detached?  Tracking this down will be a pain without this info.  One
could add a verbose option to print such info I guess, but it might
cut down on support costs if this info was always printed.

>
> Anyway, I've no real inclination for any of these possible
> outputs.
>
>> Ok to check in?
>
> This is fine with me.  Let's give it a few days in case Daniel or
> others want to comment.
>
> Thanks for documenting detach_or_kill_inferior_callback, btw ;-).
>
> --
> Pedro Alves
>