This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Patch] Mechanism for board files to set default remotetimeout
- From: Pedro Alves <palves at redhat dot com>
- To: Sterling Augustine <saugustine at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 03 Jun 2013 11:52:21 +0100
- Subject: Re: [Patch] Mechanism for board files to set default remotetimeout
- References: <CAEG7qUxhokN487WsVXgQsRj5MGv-mPw8D2WB9oT7dYRBmA3UMw at mail dot gmail dot com> <51A877BD dot 4020804 at redhat dot com> <CAEG7qUxVaxn_J7G1jhUZFryK6ekoxaYZoLfGR8+Ke5y_m0HSgA at mail dot gmail dot com>
On 05/31/2013 09:57 PM, Sterling Augustine 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.
>
>>> It follows a similar mechanism as set height 0.
>>>
>>> This is useful if the board has high latency for internal gdb
>>> commands, as remote-stdio-gdbserver.exp does.
>>
>> "high latency for internal gdb commands"?
>>
>> What does that mean? What are internal gdb commands?
>
> I meant to distinguish between the communication that happens between
> the user and gdb, and the communication that happens between gdb and
> gdbserver. Not very well, apparently.
:-) Calling those the remote serial protocol (RSP) commands would be
clearer.
>
>>
>> Testsuite knobs boards can tweak should be documented somewhere.
>> Looks like under "Testsuite Configuration" in the gdbint manual
>> might be a good place? Would be great if it was minimally
>> documented in the .exp itself too.
>
> Since I'm switching to the other mechanism, I guess I won't worry
> about this. I will however, separately submit a patch to the "set
> remotetimeout" command's documentation, mentioning that there is a
> command line option which does the same thing. Would have saved me a
> bit of trouble.
That's always nice, thanks.
Note however, given "-ex", you don't even need the special -l switch.
This
gdb -ex "set remotetimeout xxx"
works just as fine. So you can do this from the command line:
$ make check RUNTESTFLAGS="GDBFLAGS='-ex set\ remotetimeout\ 1000'"
Or, for example, this is a board file I have for testing
GDB in different modes:
~~~
set board_info(localhost,isremote) 0
load_generic_config "unix"
set GDBFLAGS ""
#set GDBFLAGS "${GDBFLAGS} -ex \"set target-async on\""
#set GDBFLAGS "${GDBFLAGS} -ex \"set break always-inserted on\""
#set GDBFLAGS "${GDBFLAGS} -ex \"set displaced-stepping on\""
# The default compiler for this target.
set_board_info compiler "[find_gcc]"
~~~
I then go and uncomment one of those lines to pick the mode I want.
and run with:
$ make check RUNTESTFLAGS="--target_board=localhost"
(I call that board file localhost.exp)
--
Pedro Alves