From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4232 invoked by alias); 3 Feb 2017 00:37:04 -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 3728 invoked by uid 89); 3 Feb 2017 00:37:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=insist, H*MI:sk:1485980, H*f:sk:1485980, H*i:sk:1485980 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 ESMTP; Fri, 03 Feb 2017 00:37:02 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 192817E9C2; Fri, 3 Feb 2017 00:37:02 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v130ax9N023684; Thu, 2 Feb 2017 19:37:00 -0500 Subject: Re: [PATCH,v2] Make language setting tests more robust To: Luis Machado , gdb-patches@sourceware.org References: <1485962220-31071-1-git-send-email-lgustavo@codesourcery.com> <1485980466-711-1-git-send-email-lgustavo@codesourcery.com> Cc: simon.marchi@polymtl.ca From: Pedro Alves Message-ID: <4423d3ac-814c-2d71-e5fd-ed27368f02e1@redhat.com> Date: Fri, 03 Feb 2017 00:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1485980466-711-1-git-send-email-lgustavo@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00082.txt.bz2 On 02/01/2017 08:21 PM, Luis Machado wrote: > One case of the warning being displayed happens when one has debug information > for glibc, which may cause GDB to identify the frame as having an "asm" > language. Therefore setting it to something else will get GDB's attention. > > This patch addresses the problem by creating a function in lib/gdb.exp to > set the language. That function will also handle potential warnings and check > to make sure the language was properly selected. Sorry to be a naysayer, but I'm not sure about this. :-( I recall fixing bugs related to gdb printing that warning when it really should not, or causing regressions locally due to breaking that logic, with the testsuite helping notice them. I worry that this would be hiding such bugs going forward. Can you name the tests that where you saw the problem you mention? Many of the tests you're touching are changing the language after starting gdb with no binary loaded, even. Those definitely should not ever warn. There are a few even that have "no prompt when changing language"-like messages. > Also, i noticed most of the languages have their own set_lang_ proc, > and they are all the same. Therefore i've removed those and switched to using > only the new set_language proc. > > I tried to confirm why set_lang_ was replicated, but my conclusion > was that it was just the way the code worked and people just copy/pasted from > an existing language .exp file. One small advantage I see is that set_lang_ is a tcl symbol, so if you typo it, you'll get a tcl error. Kind of like avoiding sprinkling magic constants in C. You could keep the wrapper procs but define them in terms of set_language, like: proc set_lang_objc {} { set_language "objective-c" } But I won't insist. > +# Set the language and handle possible warnings output by GDB if > +# we select a language that differs from the current frame's language. > +# > +# The first argument is the language to be set. > +# > +# The second argument is an optional message to be output by the test. If > +# the message is empty, the command to set the language will be used instead. > + > +proc set_language { language { message "" } } { > + global gdb_prompt > + > + set command "set language $language" > + set lang_pattern [string_to_regexp $language] > + > + if { $message == "" } { > + set message $command > + } > + > + # Switch to the user-selected language. > + gdb_test_multiple $command $message { > + -re "Undefined item: \"$lang_pattern\"\.\[\r\n\]+$gdb_prompt" { > + fail $message > + return 0 > + } > + -re "Warning: the current language does not match this frame.\[\r\n\]+$gdb_prompt $" { > + } > + -re "$gdb_prompt $" {} > + } Writing this as: set command_re [string_to_regexp $command] # Switch to the user-selected language. gdb_test_multiple $command $message { -re "Warning: the current language does not match this frame.\[\r\n\]+$gdb_prompt $" { } -re "^$command_re\r\n$gdb_prompt $" { } -re "$gdb_prompt" { fail $message return 0 } } Would be more robust in case the "Undefined item" output ever changes. Thanks, Pedro Alves