From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72643 invoked by alias); 5 Jun 2019 09:32:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 72628 invoked by uid 89); 5 Jun 2019 09:32:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=spent, H*i:sk:87blzeo, H*f:sk:87blzeo, H*f:sk:691455f X-HELO: mail-wr1-f67.google.com Received: from mail-wr1-f67.google.com (HELO mail-wr1-f67.google.com) (209.85.221.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Jun 2019 09:32:27 +0000 Received: by mail-wr1-f67.google.com with SMTP id n4so13465760wrw.13 for ; Wed, 05 Jun 2019 02:32:27 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id u19sm43114827wmu.41.2019.06.05.02.32.25 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 02:32:25 -0700 (PDT) Subject: Re: [RFC 1/2] Remove linux-waitpid.c debugging code To: Tom Tromey , Simon Marchi References: <20190530213046.20542-1-tom@tromey.com> <20190530213046.20542-2-tom@tromey.com> <691455f5-bc20-5260-b1ec-6bf57f17579f@simark.ca> <87blzeocix.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 05 Jun 2019 09:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87blzeocix.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00119.txt.bz2 On 6/3/19 5:32 PM, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > >>> My first thought was that this code is not extremely useful, so this >>> patch removes this code. (However, if it is actually useful to >>> someone, we could make it work by introducing a new abstraction.) > > Simon> Pedro probably has a stronger opinion about this (as he is probably the one who > Simon> has spent the most time staring at those logs), but I would think that this > Simon> logging is useful when debugging interactions with the kernel. > > I should have mentioned that the reason I figured it wasn't that useful > is that it's not available in gdb proper, only gdbserver. A bit of history here: IIRC, the original reason my_waitpid in gdbserver printed the result, is that I found that useful when I made my_waitpid emulate __WALL: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/gdbserver/linux-low.c;h=ba1d7b46bb96e4cec83ea698e40511d284f16532;hb=bd99dc858385792aad304d42f4a47791fd8d3272#l2110 Over the years, the function moved to gdb/nat/, gdb started using it too, and then the __WALL emulation disappeared, making my_waitpid a simple EINTR wrapper again. Since the emulation is gone, and, both gdb and gdbserver print the result of waitpid in the most interesting waitpid call spot: if (debug_threads) debug_printf ("LWFE: waitpid(-1, ...) returned %d, %s\n", ret, errno ? strerror (errno) : "ERRNO-OK"); if (debug_linux_nat) fprintf_unfiltered (gdb_stdlog, "LNW: waitpid(-1, ...) returned %d, %s\n", lwpid, errno ? safe_strerror (errno) : "ERRNO-OK"); ... I guess I won't terribly miss it. Thanks, Pedro Alves