From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E8E4738582AF for ; Mon, 7 Nov 2022 13:55:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E8E4738582AF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 55CF61E0CB; Mon, 7 Nov 2022 08:55:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1667829318; bh=WlDoqTv/+GcWKwiSmbe7FCX87X8jqCx1WViHB40/jDg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GXAlWp+XN0gU2/EX83ONCDz8xvwH5vvNtb3O7qJlDWa+397mTMeSZwyvuCcMQJBft TEAmePHfdnQOkgU1Sl5oPTlKZr+o3OZUMKXS8HhZf9W0Ysl/RW5j+FsX0Nd1/g6Asb ewsmwIwKL98XQWsatxvZCOF2WE71cStUxyoAl5+U= Message-ID: <7ab4978f-6a96-8140-7702-f2790d6281b5@simark.ca> Date: Mon, 7 Nov 2022 08:55:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 2/7] [gdb/testsuite] fix test gdb.base/print-file-var.exp for remote execution Content-Language: en-US To: Tom de Vries , Ivan Tetyushkin , gdb-patches@sourceware.org, Andrew Burgess References: <20221025162946.727169-1-ivan.tetyushkin@syntacore.com> <20221025162946.727169-3-ivan.tetyushkin@syntacore.com> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/6/22 05:54, Tom de Vries via Gdb-patches wrote: > On 10/25/22 18:29, Ivan Tetyushkin wrote: >> --- >>   gdb/testsuite/gdb.base/print-file-var.exp | 4 +++- >>   1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.base/print-file-var.exp b/gdb/testsuite/gdb.base/print-file-var.exp >> index 9abe87d7758..73137630fed 100644 >> --- a/gdb/testsuite/gdb.base/print-file-var.exp >> +++ b/gdb/testsuite/gdb.base/print-file-var.exp >> @@ -42,6 +42,8 @@ proc test {hidden dlopen version_id_main lang} { >>       set libobj1 [standard_output_file ${lib1}$suffix.so] >>       set libobj2 [standard_output_file ${lib2}$suffix.so] >>   +    set runtimelibobj2 [get_runtime_file $libobj2] >> + >>       set lib_opts { debug $lang } >>       lappend lib_opts "additional_flags=-DHIDDEN=$hidden" >>   @@ -60,7 +62,7 @@ proc test {hidden dlopen version_id_main lang} { >>       set link_opts [list debug shlib=${libobj1}] >>         if {$dlopen} { >> -    lappend main_opts "additional_flags=-DSHLIB_NAME=\"$libobj2\"" >> +    lappend main_opts "additional_flags=-DSHLIB_NAME=\"$runtimelibobj2\"" >>       lappend link_opts "shlib_load" >>       } else { >>       lappend link_opts "shlib=${libobj2}" > > I get this test-case passing by avoiding to use an absolute file name: > ... > diff --git a/gdb/testsuite/gdb.base/print-file-var.exp b/gdb/testsuite/gdb.base/print-file- > var.exp > index 9abe87d7758..338840cb05e 100644 > --- a/gdb/testsuite/gdb.base/print-file-var.exp > +++ b/gdb/testsuite/gdb.base/print-file-var.exp > @@ -60,7 +60,7 @@ proc test {hidden dlopen version_id_main lang} { >      set link_opts [list debug shlib=${libobj1}] > >      if {$dlopen} { > -       lappend main_opts "additional_flags=-DSHLIB_NAME=\"$libobj2\"" > +       lappend main_opts "additional_flags=-DSHLIB_NAME=\"[file tail $libobj2]\"" >         lappend link_opts "shlib_load" >      } else { >         lappend link_opts "shlib=${libobj2}" > ... > which means that the file is found relative to $ORIGIN, as is the case for $dlopen == 0. > > I'm not entirely happy with this fix, because what we'd rather want is to use the name as returned by remote_download, but that's done in gdb_load_shlib later on (which also handles shlib_target_file, so actually, the name as returned by this proc is the one we really want), so it's not available yet at the time we do the compilation. > > I've thought about allowing gdb_load_shlib to be called without gdb instance, and for cases where there's no instance, registering the solib-search-path setting to be done at gdb start.  This will allow us to move the gdb_load_shlib calls to before the compilation, such that we can use the result to set -DSHLIB_NAME.  But I think it's a solution bound to cause confusion because things happen under the hood. > > Alternatively, we can try to not pass in the name into compilation (working around only some of the problems related to remote host testing, see https://sourceware.org/bugzilla/show_bug.cgi?id=16947), but that also has its limitations: we need to be able to patch target memory or the ability to use argv. > > Perhaps splitting up the functionality in gdb_load_shlib makes the most sense.  By default, it'll do the same as before, but by calling it twice, once with -only-download, and once with -no-download can we get the solib name before starting gdb. > > I've given this a try in patch attached below. > > Ivan, could you check if the patch fixes the gdb.base/print-file-var.exp test-case for you? I just gave it a quick look and I'm not familiar with the entire problem. But it sounds to me like it would be clearer to just make two procs for the two steps, instead of one proc with flags to control its behavior. And perhaps a third proc that does both steps, for convenience (which would be called gdb_load_shlib for backwards compatibility, I guess). Simon