From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 945113852777 for ; Thu, 9 Jun 2022 13:40:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 945113852777 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-653-9M4G_x2gPV-kK0V4aJacqQ-1; Thu, 09 Jun 2022 09:40:11 -0400 X-MC-Unique: 9M4G_x2gPV-kK0V4aJacqQ-1 Received: by mail-wr1-f72.google.com with SMTP id h2-20020adfe982000000b002102da95c71so5561613wrm.23 for ; Thu, 09 Jun 2022 06:40:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=KiFjLN+brQwXtqSOAZhMcT0CYDViFihV8mERi1DNOWY=; b=HG5tDV4Hp+3LFMhfojqRlRWbaT3EOCfruAeyiMUkiC2/YrUmXYDU7OiOheFzfFlgU4 JGxyDhLGCHHbM/9dT63OvkDRRT3Y4gC1pvc6bsCJCY4gOP3jx8Fd9/KjLhHLMRB2rDip GV1NuA1YhU2ZqPBC2wpHJsxNsVxgT59h5JEIC2qzQRdyjxt7mey7h6RAG02HKZKQ6dvf 3mZNiCDL/tlF1tO58h38w00gB1JxoUvjaPqQirXCaAjZmDC7XY7ca5ISuNl6nktg5Tot AhWdHiv5XYRl9GFE/JPXGmbn7AARGMyGdwaDk+pFDob7ZH4o1DtqN1JOM7GIajr0nXQH ag4w== X-Gm-Message-State: AOAM531g54NIV3Pp0p03de4cgjecsT3mK9p+HHAJALlbpwaljqqMR6DZ Blif4kB2UZoOytEKzRqA9xNYMedHvG66LQG34e2lMxX60/827cEYrlBn6etbc9j4rQimX1v0Fm3 HGou21NEKM9tkEKKCiwQ+kA== X-Received: by 2002:a5d:6da3:0:b0:219:bcdd:97cd with SMTP id u3-20020a5d6da3000000b00219bcdd97cdmr1630244wrs.274.1654782009734; Thu, 09 Jun 2022 06:40:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwW7QOtmWOTp3hgdkIfvn395/qi88HRqlAt2SppQ72PCTB2M4/kv4f3i6r590sl8gGmLudbQg== X-Received: by 2002:a5d:6da3:0:b0:219:bcdd:97cd with SMTP id u3-20020a5d6da3000000b00219bcdd97cdmr1630223wrs.274.1654782009513; Thu, 09 Jun 2022 06:40:09 -0700 (PDT) Received: from localhost (host109-152-215-36.range109-152.btcentralplus.com. [109.152.215.36]) by smtp.gmail.com with ESMTPSA id s3-20020a5d6a83000000b0020cfed0bb7fsm24469790wru.53.2022.06.09.06.40.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 06:40:08 -0700 (PDT) From: Andrew Burgess To: "Kempke\, Nils-Christian" , "gdb-patches\@sourceware.org" Subject: RE: [PATCH 3/5] gdb/testsuite: make 'c' default language for get/test compiler info In-Reply-To: References: <871qvzgrwd.fsf@redhat.com> <950a3ff84295fa8f3daacb08c489e874712ca194.1654697966.git.aburgess@redhat.com> Date: Thu, 09 Jun 2022 14:40:07 +0100 Message-ID: <87leu6ez0o.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 13:40:14 -0000 "Kempke, Nils-Christian via Gdb-patches" writes: >> -----Original Message----- >> From: Gdb-patches > christian.kempke=intel.com@sourceware.org> On Behalf Of Andrew >> Burgess via Gdb-patches >> Sent: Wednesday, June 8, 2022 4:22 PM >> To: gdb-patches@sourceware.org >> Cc: Andrew Burgess >> Subject: [PATCH 3/5] gdb/testsuite: make 'c' default language for get/test >> compiler info >> >> This commit is a minor cleanup for the two functions (in gdb.exp) >> get_compiler_info and test_compiler_info. >> >> Instead of using the empty string as the default language, and just >> "knowing" that this means the C language. Make this explicit. The >> language argument now defaults to "c" if not specified, and the if >> chain in get_compiler_info that checks the language not explicitly >> handles "c" and gives an error for unknown languages. >> >> This is a good thing, now that the API appears to take a language, if >> somebody does: >> >> test_compiler_info "xxxx" "rust" >> >> to check the version of the rust compiler then we will now give an >> error rather than just using the C compiler and leaving the user >> having to figure out why they are not getting the results they >> expect. >> >> After a little grepping, I think the only place we were explicitly >> passing the empty string to either get_compiler_info or >> test_compiler_info was in gdb_compile_shlib_1, this is now changed to >> pass "c" as the default language. > > I think there is one more: in build_executable_and_dwo_files in dwarf.exp > we also call get_compiler_info with the $language variable which is set to > "" when the language is not given as "c++" in the procedure's options. > >> >> There should be no changes to the test results after this commit. >> --- >> gdb/testsuite/lib/gdb.exp | 21 +++++++++++++-------- >> 1 file changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index b779bff81e6..140da05b35e 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -4097,7 +4097,7 @@ set gcc_compiled 0 >> # >> # -- chastain 2004-01-06 >> >> -proc get_compiler_info {{arg ""}} { >> +proc get_compiler_info {{language "c"}} { >> # For compiler.c, compiler.cc and compiler.F90. >> global srcdir >> >> @@ -4117,11 +4117,15 @@ proc get_compiler_info {{arg ""}} { >> } >> >> # Choose which file to preprocess. >> - set ifile "${srcdir}/lib/compiler.c" >> - if { $arg == "c++" } { >> + if { $language == "c++" } { >> set ifile "${srcdir}/lib/compiler.cc" >> - } elseif { $arg == "f90" } { >> + } elseif { $language == "f90" } { >> set ifile "${srcdir}/lib/compiler.F90" >> + } elseif { $language == "c" } { >> + set ifile "${srcdir}/lib/compiler.c" >> + } else { >> + perror "Unable to fetch compiler version for language: $language" >> + return -1 >> } >> >> # Run $ifile through the right preprocessor. >> @@ -4132,12 +4136,12 @@ proc get_compiler_info {{arg ""}} { >> # We have to use -E and -o together, despite the comments >> # above, because of how DejaGnu handles remote host testing. >> set ppout "$outdir/compiler.i" >> - gdb_compile "${ifile}" "$ppout" preprocess [list "$arg" quiet >> getting_compiler_info] >> + gdb_compile "${ifile}" "$ppout" preprocess [list "$language" quiet >> getting_compiler_info] >> set file [open $ppout r] >> set cppout [read $file] >> close $file >> } else { >> - set cppout [ gdb_compile "${ifile}" "" preprocess [list "$arg" quiet >> getting_compiler_info] ] >> + set cppout [ gdb_compile "${ifile}" "" preprocess [list "$language" >> quiet getting_compiler_info] ] >> } >> eval log_file $saved_log >> >> @@ -4193,7 +4197,7 @@ proc get_compiler_info {{arg ""}} { >> # Otherwise the argument is a glob-style expression to match against >> # compiler_info. >> >> -proc test_compiler_info { {compiler ""} {language ""} } { >> +proc test_compiler_info { {compiler ""} {language "c"} } { >> global compiler_info >> get_compiler_info $language >> >> @@ -4767,11 +4771,12 @@ proc gdb_compile_shlib_1 {sources dest options} >> { >> set ada 1 >> } >> >> - set info_options "" >> if { [lsearch -exact $options "c++"] >= 0 } { >> set info_options "c++" >> } elseif { [lsearch -exact $options "f90"] >= 0 } { >> set info_options "f90" >> + } else { >> + set info_options "c" >> } >> >> switch -glob [test_compiler_info ${info_options}] { > > I am wondering whether these lines ever did what was intended. The proc > test_compiler_info takes 2 arguments, the string to match against defaulted > to "" and the language defaulted to "c". So by writing test_compiler_info ${info_options}, > would we not call test_compiler_info "${info_options}" "c", specializing the first but not > the second argument? > I think this line tires to use the "Return the compiler_info string if no arg is provided" version > of test_compiler_info, which would be > test_compiler_info "" ${info_options} > here. As far as me grepping the testsuite goes this is the only call like this.. Thanks for spotting both these issues. The fixes for these better fit in patch #2. I've posted an updated version of that patch that should resolve these two issues. Thanks, Andrew