From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2183 invoked by alias); 10 Jul 2014 16:15:14 -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 2159 invoked by uid 89); 10 Jul 2014 16:15:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 10 Jul 2014 16:15:09 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6AGF1v2018655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Jul 2014 12:15:02 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6AGExnQ011570; Thu, 10 Jul 2014 12:14:59 -0400 Message-ID: <53BEBC02.20208@redhat.com> Date: Thu, 10 Jul 2014 16:15:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Tom Tromey , Keith Seitz , Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [PATCH v2] GDB/testsuite: Add a way to send multiple init commands References: <87a99jwj4u.fsf@fleche.redhat.com> <53A3F5BD.2030709@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg00207.txt.bz2 On 07/10/2014 01:17 AM, Maciej W. Rozycki wrote: > On Fri, 20 Jun 2014, Pedro Alves wrote: > >>> 2014-06-11 Maciej W. Rozycki >>> Maciej W. Rozycki >>> >>> * lib/gdb.exp (gdb_run_cmd): Process `gdb_init_commands'. >>> * lib/mi-support.exp (mi_run_cmd): Process `gdb_init_commands'. >>> * README (Board Settings): Document `gdb_init_command' and >>> `gdb_init_commands'. >> >> I don't particularly see much need for this -- I do this in my >> boards instead: >> >> set GDBFLAGS "" >> set GDBFLAGS "${GDBFLAGS} -ex \"set breakpoint always-inserted on\"" >> set GDBFLAGS "${GDBFLAGS} -ex \"set target-async 1\"" >> >> See: >> >> https://sourceware.org/gdb/wiki/TestingGDB#Passing_an_option_to_GDB_.2BAC8_Running_the_whole_test_suite_in_a_non-default_mode >> >> But, given gdb_init_command exists and this can be made >> non-intrusive, it's fine with me to add the new option. > > That and I think there are two issues with passing commands as > command-line arguments: > > 1. They are always executed, perhaps unnecessarily whereas > `gdb_init_command' and consequently `gdb_init_commands' are only > interpreted when a target connection is about to be made (this is more > of an aesthetic matter, but still). Which I'll guess is an historic accident (not by design) given the option's name. I'd think hooking gdb_reload/gdb_load would do just as well. > > 2. Some environments have a limit, maybe quite low, on the maximum length > of a command line or command-line arguments they accept (now that is > more real). Not really an issue, as you can just put the commands in a GDB script and do: set GDBFLAGS "${GDBFLAGS} -x \"/path/to/script.gdb\"" Very much like a response file. > > BTW, in updating DejaGNU documentation that refers to `gdb_init_command' > I've noticed it lists a command that pokes at a CPU register there -- has > the semantics of the setting changed sometime, perhaps long ago? Does > anybody know/remember? I don't know the history, but I'd guess it's related to this in config/gdb-comm.exp (found in dejagnu itself, not gdb): # # gdb_comm_load -- load the program and execute it # # PROG is a full pathname to the file to load, no arguments. # Result is "untested", "pass", "fail", etc. # proc gdb_comm_load { dest prog args } { ... remote_send host "target $protocol $targetname\n" remote_expect host 60 { ... if {[target_info exists gdb_init_command]} { remote_send host "[target_info gdb_init_command]\n" remote_expect host 10 { -re ".*$gdb_prompt $" { } default { gdb_comm_leave return [list "fail" ""] } } } ... } So in that board, gdb_init_command runs after connecting, and is used to configure the board after connecting. Clearly there's a usage conflict here... (that's a ${board}_load override, note.) I'd guess most of what's in that file predates all the equivalent infrastructure we have, even. Maybe gdb_init_command started out there before in appeared in gdb's codebase. But that's just guesswork. I wasn't around then. :-) I have no idea if gdb-comm.exp is still used. > Done, as below, and retested. Any other questions or comments? > Otherwise OK to apply? This version looks good to me. Thanks, -- Pedro Alves