On Mon, Apr 13, 2009 at 11:49 AM, Doug Evans wrote: > On Sat, Apr 11, 2009 at 8:04 AM, Pedro Alves 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 >> > Ok to check this in? It does Killing process(es) PID1, PID2, PID3, PID4, PIDnn. Detaching process(es) PID1, PID2, PID3, PID4, PIDnn. though I removed the commas for simplicity. [I'm proactively avoiding some of the issues being raised. :-)]