From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7677 invoked by alias); 18 Apr 2005 21:46:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7636 invoked from network); 18 Apr 2005 21:46:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 18 Apr 2005 21:46:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3ILkWPC006824 for ; Mon, 18 Apr 2005 17:46:32 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3ILkVO25574; Mon, 18 Apr 2005 17:46:31 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j3ILkUth026467; Mon, 18 Apr 2005 17:46:30 -0400 Message-ID: <42642AB5.7090801@redhat.com> Date: Mon, 18 Apr 2005 21:46:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Stan Shebs CC: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] testsuite: gdb_run_cmd tweak References: <42640FA7.9090406@redhat.com> <426429B8.50701@apple.com> In-Reply-To: <426429B8.50701@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00206.txt.bz2 Stan Shebs wrote: > Michael Snyder wrote: > >> This just adds a regular expression to prevent gdb_run_cmd >> from choking on the msg that gdb emits when it detects that >> the file has changed and re-reads the symbols. >> >> I honestly don't remember the circumstances that caused me >> to add this -- it's been sitting in my sandbox for a while. >> Thought it would be better to offer it up than to throw it >> away... > > > Wouldn't a message like this be symptomatic of failure > in GDB's executable date detection code, or in the executable > production bits? If I understand it, we get that message precisely when gdb's executable date detection code works as intended. It discovers that the executable's modification date has changed, and therefore re-reads the symbols. > I think we'd only want this suppression > if the situation were explicitly known to be unavoidable, > like an outside compiler we couldn't control, or a known > OS bug, and even then we'd want to conditionalize on config. > > Stan > >