Re: [Patch] Mechanism for board files to set default remotetimeout

[Pedro Alves <palves@redhat.com>]

On 05/31/2013 11:49 PM, Sterling Augustine wrote:
> On Fri, May 31, 2013 at 1:57 PM, Sterling Augustine
> <saugustine@google.com> wrote:
>> On Fri, May 31, 2013 at 3:13 AM, Pedro Alves <palves@redhat.com> 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