From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12342 invoked by alias); 12 Jul 2014 00:42:31 -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 12304 invoked by uid 89); 12 Jul 2014 00:42:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 12 Jul 2014 00:42:28 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1X5lOS-0001IV-2h from Maciej_Rozycki@mentor.com ; Fri, 11 Jul 2014 17:42:24 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jul 2014 17:42:23 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 12 Jul 2014 01:42:21 +0100 Date: Sat, 12 Jul 2014 04:38:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Tom Tromey , Keith Seitz , Eli Zaretskii , Subject: Re: [PATCH v2] GDB/testsuite: Add a way to send multiple init commands In-Reply-To: <53BEBC02.20208@redhat.com> Message-ID: References: <87a99jwj4u.fsf@fleche.redhat.com> <53A3F5BD.2030709@redhat.com> <53BEBC02.20208@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-07/txt/msg00299.txt.bz2 On Thu, 10 Jul 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. That I have a separate patch for. ;) The thing is some actions can only be requested before the target is opened and some actions can only be made afterwards. Consider setting `remotetimeout' for a crawler target and poking at a control register required to set the correct mode of execution as two representative examples. If you think it would be a worthwhile addition, then I can reorder the change to the fromt of my queue; otherwise it'll have to wait for its turn as that's for a change stuff we haven't used recently and therefore I don't consider it very important. > > 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. Fair enough. > > 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. Thanks for the pointer, I didn't expect it was a place to look there. There's this comment at the top of gdb-comm.exp: # Note: some of this was cribbed from the gdb testsuite since we need # to use some pretty standard gdb features (breakpoints in particular). so I suppose some of that stuff was somehow forked off our infrastructure sometime, probably long ago. There's a bunch of board description files in DejaGNU that pull this gdb-comm.exp harness; many actually don't do anything beyond. It may need some further investigation and maybe synchronising things between DejaGNU and our stuff. I'll talk to the DejaGNU maintainer, he seems to have been around for a while and may remember what this all is about. > > Done, as below, and retested. Any other questions or comments? > > Otherwise OK to apply? > > This version looks good to me. Committed now, thanks for your review. Maciej