From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25165 invoked by alias); 3 Jun 2013 11:31:10 -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 25156 invoked by uid 89); 3 Jun 2013 11:31:10 -0000 X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 03 Jun 2013 11:31:08 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r53BV5Eb012532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Jun 2013 07:31:05 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r53BV4qv003239; Mon, 3 Jun 2013 07:31:04 -0400 Message-ID: <51AC7E78.2000501@redhat.com> Date: Mon, 03 Jun 2013 11:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Sterling Augustine CC: gdb-patches Subject: Re: [Patch] Mechanism for board files to set default remotetimeout References: <51A877BD.4020804@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00010.txt.bz2 On 05/31/2013 11:49 PM, Sterling Augustine wrote: > On Fri, May 31, 2013 at 1:57 PM, Sterling Augustine > wrote: >> On Fri, May 31, 2013 at 3:13 AM, Pedro Alves wrote: >>> On 05/31/2013 12:42 AM, Sterling Augustine wrote: >>>> The enclosed simple patch adds and demonstrates a new mechanism for a >>>> board file to declare a default remotetimeout. >>> >>> Took me a bit to realize this is about "set remotetimeout" in gdb, >>> not the expect timeout. It wasn't that obvious from the >>> description. :-) >>> >>> Is this really necessary? The board could just append "-l TIMEOUT" >>> to the GDB command line invocation. Looks simpler, and doesn't >>> depend on issuing an interactive GDB command. >> >> I'll switch to this. > > How does this look? I considered using GDBFLAGS instead of > INTERNAL_GDBFLAGS, but lots of tests replace GDBFLAGS with their own > copy, preventing its use in many cases. Can you show an example? If a test is doing that, it's broken. >From gdb.exp: # GDBFLAGS is available for the user to set on the command line. # E.g. make check RUNTESTFLAGS=GDBFLAGS=mumble # Testcases may use it to add additional flags, but they must: # - append new flags, not overwrite # - restore the original value when done global GDBFLAGS if ![info exists GDBFLAGS] { set GDBFLAGS "" } Not sure about the extra $REMOTE_TIMEOUT knob in the board file, causing board divergence, given you can pass "GDBFLAGS=-l xxx" to all boards just as easily -- as in, what's the point of the extra knob? Sounds like what we need is better documentation? Added: http://sourceware.org/gdb/wiki/TestingGDB#Running_GDB_with_a_larger_remote_serial_protocol_timeout (If a new-knob is indeed justifiable then I'd prefer taking a step back and consider again doing it centrally...) -- Pedro Alves