From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2755 invoked by alias); 22 Apr 2008 22:09:16 -0000 Received: (qmail 2745 invoked by uid 22791); 22 Apr 2008 22:09:15 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Apr 2008 22:08:57 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m3MM8oLT010984 for ; Tue, 22 Apr 2008 23:08:51 +0100 Received: from wa-out-1112.google.com (wafl24.prod.google.com [10.114.188.24]) by zps78.corp.google.com with ESMTP id m3MM89Wn032554 for ; Tue, 22 Apr 2008 15:08:49 -0700 Received: by wa-out-1112.google.com with SMTP id l24so3789974waf.17 for ; Tue, 22 Apr 2008 15:08:49 -0700 (PDT) Received: by 10.114.190.6 with SMTP id n6mr15438waf.131.1208902129734; Tue, 22 Apr 2008 15:08:49 -0700 (PDT) Received: by 10.115.107.18 with HTTP; Tue, 22 Apr 2008 15:08:49 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 02:19:00 -0000 From: "Doug Evans" To: gdb-patches@sourceware.org Subject: Re: [RFC] gdb could leave inferior running as a background process In-Reply-To: <20080422203926.GA31285@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ac60eac0804220741g6b830620h6f83c627fb00474b@mail.gmail.com> <20080422155548.GA13076@caradoc.them.org> <8ac60eac0804220946r689605e1pd4803c2aea3a9e07@mail.gmail.com> <8ac60eac0804221051p6ad56743g202a6f920d1c6315@mail.gmail.com> <20080422180459.GB20664@caradoc.them.org> <8ac60eac0804221240k4a238445vfba927e22aff93f0@mail.gmail.com> <20080422195515.GA28506@caradoc.them.org> <20080422203926.GA31285@caradoc.them.org> X-IsSubscribed: yes 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 X-SW-Source: 2008-04/txt/msg00492.txt.bz2 On Tue, Apr 22, 2008 at 1:39 PM, Daniel Jacobowitz wrote: > On Tue, Apr 22, 2008 at 01:36:01PM -0700, Doug Evans wrote: > > It seems like there are multiple places where this can happen. E.g. > > wait_for_inferior -> handle_inferior_event -> find_pc_partial_function > > -> target_terminal_ours_for_output. > > But by then it's stopped, right? As long as something makes sure we > give the terminal back after the warning it shouldn't be a problem. Ah. It's hard to reason about correctness in this part of gdb. I can see that keep_going calls target_terminal_inferior, but the code paths are embedded in a big hairy state machine. [I've seen what wait_for_inferior used to be, things *have* improved though.]