From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7160 invoked by alias); 16 May 2013 00:59:39 -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 7149 invoked by uid 89); 16 May 2013 00:59:38 -0000 X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from elasmtp-junco.atl.sa.earthlink.net (HELO elasmtp-junco.atl.sa.earthlink.net) (209.86.89.63) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 16 May 2013 00:59:37 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UcmXg-0007WJ-23 for gdb-patches@sourceware.org; Wed, 15 May 2013 20:59:36 -0400 Message-ID: <51942F77.5000909@earthlink.net> Date: Thu, 16 May 2013 00:59:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC] Don't create inferior in tfile target. References: <1367631071-20079-1-git-send-email-yao@codesourcery.com> <5193AAD0.1030808@redhat.com> In-Reply-To: <5193AAD0.1030808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9405fec58a159bf09127e63a67b9bfb1eb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-SW-Source: 2013-05/txt/msg00565.txt.bz2 On 5/15/13 8:33 AM, Pedro Alves wrote: > On 05/04/2013 02:31 AM, Yao Qi wrote: >> In ctf target, we don't create inferior when open ctf trace file, >> however we do it in tfile target. After read the code for a while, I >> don't see any reason that we need an inferior here. The code was >> added along with the tfile support patch, and was modified once by >> patch [1] >> >> I checked out the code on the revision before patch [1] was applied >> bd196e7a61b03f2ea7e5dcb0aecbd49d239d6390 and I am able to reproduce >> the same internal error, However, I am wondering why do we need >> inferior in tfile target. I removed the code to create inferior in >> tfile_open and remove inferior in tfile_close. The internal error can >> be fixed also. I also checked that 'info threads' and 'info >> inferiors' works properly. >> >> I talked with Stan (he wrote tfile supported code) on this, but we were >> unable to recall the reason in details on creating inferior. I post >> this patch to remove the code to create inferior in tfile target. >> Comments are welcome. > > I have a very vague recollection that it was I who suggested this > in internal reviews at the time, but GDB was a bit different then, > and I don't recall exactly why. It's possible you might find that > in CS's archives. We've poked around those, haven't found anything specific. At the time we were also working on multi-process support and other ideas, it might simply be that it seemed like it was going to be required in the near future. (Wouldn't be the first time that Stan added gratuitous future-anticipating code, ahem.) > The whole tfile/tracepoints model is weird, in that it's hacked > on, and bypasses the whole target stack model. You get > things like, while inspecting a traceframe (on targets where > threads are a kernel entity), "info threads" lists you the threads > the live target happens to have at the moment. Same with shared > libraries, etc. This could/should probably be revisited once > gdb learns about being connected to multiple targets simultaneously. Heh, yeah, we've certainly discussed that ourselves, and I remember multiple discussions with Andrew, Michael, etc on the subject as well. I take the view that the target stack is a flawed concept, in that it makes sense for the simple exec/process/core trio, and breaks down for just about every other situation. It has needed hacks and workarounds ever since it was introduced ("strata", etc). It probably wouldn't even be that hard to replace with a functional model where you pass an inheritance chain to a manipulating function and get back a new chain that may be arbitrarily different ("push" and "pop" being two common cases); the amount of code involved is less than has been changed in other recent restructuring projects. Stan stan@codesourcery.com