From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124525 invoked by alias); 23 Apr 2019 11:42:06 -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 123562 invoked by uid 89); 23 Apr 2019 11:42:05 -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,T_COMPENSATION autolearn=ham version=3.3.1 spammy=leader, complaints, recall, suggesting X-HELO: mail-wr1-f50.google.com Received: from mail-wr1-f50.google.com (HELO mail-wr1-f50.google.com) (209.85.221.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Apr 2019 11:42:04 +0000 Received: by mail-wr1-f50.google.com with SMTP id o12so16484154wrn.2 for ; Tue, 23 Apr 2019 04:42:03 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id o6sm32641372wre.60.2019.04.23.04.42.00 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 04:42:00 -0700 (PDT) Subject: Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global To: =?UTF-8?B?QW5kcsOpIFDDtm5pdHo=?= References: <1555453982-77808-3-git-send-email-brobecker@adacore.com> <83imvcg0ud.fsf@gnu.org> <20190417173842.GA14817@adacore.com> <83wojseb9c.fsf@gnu.org> <20190417221729.GA5839@adacore.com> <9c75d158-6a73-d414-4cb2-17297d4576c6@redhat.com> <20190419204326.GA9601@adacore.com> <20190422152327.GA10697@klara.mpi.htwm.de> <7f39cca0-c200-430e-e885-32cc347207d0@redhat.com> <20190422214607.GA2372@klara.mpi.htwm.de> Cc: Joel Brobecker , Eli Zaretskii , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <9e51c3bc-9875-6465-5332-f92f54f6aa03@redhat.com> Date: Tue, 23 Apr 2019 11:42: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: <20190422214607.GA2372@klara.mpi.htwm.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-04/txt/msg00448.txt.bz2 On 4/22/19 10:46 PM, André Pönitz wrote: > On Mon, Apr 22, 2019 at 06:28:55PM +0100, Pedro Alves wrote: >> On 4/22/19 4:23 PM, André Pönitz wrote: >>> On Mon, Apr 22, 2019 at 03:24:46PM +0100, Pedro Alves wrote: >>>> I don't see the asymmetry (silent at creation, not silent at destruction) >>>> in this particular case as surprising [...] >>> >>> It's not surprising, but it's inconsistent >>> and causes extra work in >>> cases one wants to mechanically examine such output. >> >> I'm curious about what extra work you're thinking of. > > As far as I understand it, any (non-MI) user wanting to keep track of > running threads would need to find out which events are "not surprising" > (for which version of GDB...) and mentally (or in code) "generate" > the "missing" events. That's a kind of "work". gdb on GNU/Linux already works like I'm suggesting, and has been doing it for a few years, and I don't think I recall ever hearing complaints about it: Simple single-threaded "hello world" program: (gdb) r Starting program: /home/pedro/brno/pedro/gdb/tests/main [Inferior 1 (process 13298) exited normally] (gdb) Multi-threaded program that exits normally (gdb.threads/schedlock.exp testcase): (gdb) r Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff74b8700 (LWP 13984)] <<< extra thread [Thread 0x7ffff74b8700 (LWP 13984) exited] <<< extra thread exits [Inferior 1 (process 13980) exited normally] (gdb) Threaded program that has the leader thread exit with pthread_exit while another thread keeps running (gdb.threads/leader-exit.exp testcase): (gdb) r Starting program: build/gdb/testsuite/outputs/gdb.threads/leader-exit/leader-exit [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff74b8700 (LWP 13230)] <<<< extra thread [Thread 0x7ffff7fb6740 (LWP 13226) exited] <<<< leader thread exits (notice LWP == process ID) [Inferior 1 (process 13226) exited normally] (gdb) Note there's some time between the leader exiting, and the process exiting. If the output were changed like I was suggesting, we'd have something like this, which I think would be much clearer: (gdb) r Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 1.2 (0x7ffff74b8700 (LWP 13984))] [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited] [Inferior 1 (process 13980) exited normally] (gdb) And: (gdb) r Starting program: build/gdb/testsuite/outputs/gdb.threads/leader-exit/leader-exit [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 1.2 (0x7ffff74b8700 (LWP 13230))] [Thread 1.1 (0x7ffff7fb6740 (LWP 13226)) exited] [Inferior 1 (process 13226) exited normally] (gdb) We're going on a tangent, but maybe even say "Thread ... appeared" instead of "New Thread", for better visual alignment, like: (gdb) r Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) appeared] [Thread 1.2 (0x7ffff74b8700 (LWP 13984)) exited] [Inferior 1 (process 13980) exited normally] (gdb) > >> Can't think of anything significant. > > It's not significant, but less surprising to me personally, i.e. > violating the principle of least astonishment. > >> But do note that this discussion does not affect MI. > > I understand that, and for thread related notifications MI is sufficient > for my frontend purposes, but in general MI does not cover all functionality > of CLI and already this discrepancy is a surprise to some degree. I'd > rather see the differences go away over time, not to increase. > >> So what do you propose? My proposal kept these two ideas in mind: >> >> - be quiet wrt to threads with single-threaded programs. > > TBH, I don't see the necessity of this requirement. That would be two > lines of noise per run. I think I had originally proposed that when I switched gdb's model to "always a thread", but got pushed back. And I do think the pushback made sense, particularly when you consider remote debugging targets that don't even have a concept of threads. I kind of convinced myself by considering bare metal targets, but also considering further "execution unit" levels/layers -- say gdb adds native support for fibers, and the model is that the initial thread has an initial fiber too -- i.e., there's always a fiber, like there's always a thread. Would we want to automatically announce the initial fiber as soon as the process starts, even if the process doesn't make use of fibers? (gdb) r Starting program: ... [New Thread 1.1 ...] [New Fiber 1.1 ...] ..... [Fiber 1.1 ... exited] [Thread 1.1 exited] [Inferior 1 (process 13226) exited normally] (gdb) Or, would we rather be quiet about fibers until something creates a second one, similarly to how we are quiet about threads until a second thread is created? And fibers would be one kind of unit of execution. There may be others. What to do then? > >> - inform the user the main thread exited while other threads stay running. > > Also here, I don't see enough gain in one suppressed line of output > to compensate for the inconsistency, this time even with a CLI user hat on. Thanks, Pedro Alves