Message ID | 81337265-2508-4e7a-1acc-4bf09b664f42@polymtl.ca |
---|---|
State | New, archived |
Headers |
Received: (qmail 28788 invoked by alias); 15 Dec 2019 04:09:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 28779 invoked by uid 89); 15 Dec 2019 04:09:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=March, absence, Shouldnt, Shouldn't X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Dec 2019 04:09:42 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id xBF49WVP025600 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Dec 2019 23:09:37 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca xBF49WVP025600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1576382978; bh=hGNVMLfsvWz16wQeQHS8DkLsxHwLoArxw1E+Q0vHkW4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dhBWO0RPZvW3+K7LOVQ3tbmAhvL2kWfgziMRyjFPuZBVf7fW2LYBqsOsx/e85uZNj 31HFsT3vexoAYJzD2Rzx99xyMEN7+N73AnhLlRoJqzIG3eJMwBaM4nbVO1AC4yur3O OPaV8Nc4u9pYp7P/rQo2mczJ/os9Nd+mBxMTmQX8= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 21ABE1E50B; Sat, 14 Dec 2019 23:09:32 -0500 (EST) Subject: Re: Question for Ada people, debugging gdb.ada/ptype_tagged_param.exp To: Joel Brobecker <brobecker@adacore.com> Cc: GDB patches <gdb-patches@sourceware.org> References: <070fa9d7-a4bc-e9e3-4f8d-bb2959846251@polymtl.ca> <20191208005143.GA21428@adacore.com> <763a224e-8f53-4c8b-5880-03991fbb49b2@polymtl.ca> <20191212224820.GB13716@adacore.com> From: Simon Marchi <simon.marchi@polymtl.ca> Message-ID: <81337265-2508-4e7a-1acc-4bf09b664f42@polymtl.ca> Date: Sat, 14 Dec 2019 23:09:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20191212224820.GB13716@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes |
Commit Message
Simon Marchi
Dec. 15, 2019, 4:09 a.m. UTC
On 2019-12-12 5:48 p.m., Joel Brobecker wrote: > FWIW, this is really about the runtime, so I would mention it > in the name of the function. Noted. > The other thing you might want to be careful of is that, on some > platforms, the gnat runtime used for linking by default is the > shared libgnat. So, if you want to check for the presence of > a given symbol, you would have to start the program first. > Shouldn't be a big issue, I believe; you just have to run until > reaching a known subprogram in the inferior. I did that, it doesn't seem to be a problem. > The approach of checking for a given symbol to infer whether > the runtime as a whole has the necessary debug info for a given > test should work in practice -- as I do not a situation where > only part of the units that need debugging info have debug info, > but not others, is worth worrying about. > > Probably one good function to look for is the following: > > __gnat_debug_raise_exception Great, thanks. > The thing with these internal functions is that they are subject > to change. We try not to, but this has happened as you can see > from the various declarations of struct exception_support_info > objects in ada-lang.c (search for default_exception_support_info). > Luckily, I think this one has been quite stable (unchanged since > March 2007 according to one of the comments0, and I am hoping > will remain the same for a veeeery long time. And even if it changes, we can adapt the test easily. Here's a patch. It works on a runtime without debug info, but I'll need your help to test it on a runtime with debug info, as I didn't find a configuration that worked. I tried to install the libgnat-7-dbg package on Ubuntu 18.04, but it didn't help. From 431f8d1d6ff7dd343a4c35ab67318a44690abd4b Mon Sep 17 00:00:00 2001 From: Simon Marchi <simon.marchi@polymtl.ca> Date: Sat, 14 Dec 2019 22:16:05 -0500 Subject: [PATCH] Adjust test gdb.ada/ptype_tagged_param.exp for when GNAT runtime does not have debug info This test verifies that GDB correctly identifies the run-time type of "s" as being the type "Circle". However, that can only be done correctly if the GNAT runtime has been compiled and shipped with debug information, so that GDB can poke in its internal data structures. Currently the test fails when when running against a GNAT runtime without debug info. This is the case, for example, on Arch Linux using the distribution package. This patch adds a helper in lib/ada.exp to check whether the GNAT runtime has debug info or not. It then uses it in gdb.ada/ptype_tagged_param.exp to expect a different result, depending on whether we have debug info or not in the runtime. At first, I made it so we would XFAIL the test, in the absence of debug info, but then I thought that we might as well test for the output we expect in the absence of debug info instead. gdb/testsuite/ChangeLog: * lib/ada.exp (gnat_runtime_has_debug_info): New proc. * lib/gnat-debug-info-test.adb: New file. * gdb.ada/ptype_tagged_param.exp: Use gnat_runtime_has_debug_info, expect a different output if runtime does not have debug info. --- gdb/testsuite/gdb.ada/ptype_tagged_param.exp | 22 +++++++++--- gdb/testsuite/lib/ada.exp | 36 ++++++++++++++++++++ gdb/testsuite/lib/gnat-debug-info-test.adb | 6 ++++ 3 files changed, 60 insertions(+), 4 deletions(-) create mode 100644 gdb/testsuite/lib/gnat-debug-info-test.adb
Comments
Hi Simon, Sorry for the delay in answering you. I've been meaning to answer for the last couple of weekends, but I haven't managed to find the time due to travels :-(. > Here's a patch. It works on a runtime without debug info, but I'll need > your help to test it on a runtime with debug info, as I didn't find a > configuration that worked. I tried to install the libgnat-7-dbg package > on Ubuntu 18.04, but it didn't help. Thanks, Simon. > >From 431f8d1d6ff7dd343a4c35ab67318a44690abd4b Mon Sep 17 00:00:00 2001 > From: Simon Marchi <simon.marchi@polymtl.ca> > Date: Sat, 14 Dec 2019 22:16:05 -0500 > Subject: [PATCH] Adjust test gdb.ada/ptype_tagged_param.exp for when GNAT > runtime does not have debug info > > This test verifies that GDB correctly identifies the run-time type of > "s" as being the type "Circle". However, that can only be done > correctly if the GNAT runtime has been compiled and shipped with debug > information, so that GDB can poke in its internal data structures. > Currently the test fails when when running against a GNAT runtime > without debug info. This is the case, for example, on Arch Linux using > the distribution package. > > This patch adds a helper in lib/ada.exp to check whether the GNAT > runtime has debug info or not. It then uses it in > gdb.ada/ptype_tagged_param.exp to expect a different result, depending > on whether we have debug info or not in the runtime. > > At first, I made it so we would XFAIL the test, in the absence of debug > info, but then I thought that we might as well test for the output we > expect in the absence of debug info instead. FWIW, I don't mind checking for the result that we get when the runtime is missing the debugging information. The only downside I see is that the expected behavior is less predictable: It depends on both the implementation chosen by the compiler, which can change over time, and also across targets, but can also depend on GDB's implementation choices too. For my money, I think the most practical approach is to actually say "this test requires debugging information from the runtime, so if you do not have it, then the testcase cannot be run", in which case we return UNSUPPORTED instead of returning an XFAIL or changing the expected output. I like your approach because it forces us to test GDB more thouroughly, and in particular it verifies the behavior when in degraded mode. We should just be aware that this would be at the cost of some occasional testcase maintenance work, when anything affecting the somewhat unspecified outcome changes. > gdb/testsuite/ChangeLog: > > * lib/ada.exp (gnat_runtime_has_debug_info): New proc. > * lib/gnat-debug-info-test.adb: New file. > * gdb.ada/ptype_tagged_param.exp: Use > gnat_runtime_has_debug_info, expect a different output if > runtime does not have debug info. I tested this patch, and found a thinko-bug. See below. > --- > gdb/testsuite/gdb.ada/ptype_tagged_param.exp | 22 +++++++++--- > gdb/testsuite/lib/ada.exp | 36 ++++++++++++++++++++ > gdb/testsuite/lib/gnat-debug-info-test.adb | 6 ++++ > 3 files changed, 60 insertions(+), 4 deletions(-) > create mode 100644 gdb/testsuite/lib/gnat-debug-info-test.adb > > diff --git a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp > index 567ef8251d9f..87a676c9ca24 100644 > --- a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp > +++ b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp > @@ -21,14 +21,28 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } > return -1 > } > > +set has_runtime_debug_info [gnat_runtime_has_debug_info] > + > clean_restart ${testfile} > > if ![runto "position_x" ] then { > return -1 > } > > -set eol "\[\r\n\]+" > -set sp "\[ \t\]*" > +if { $has_runtime_debug_info } { > + gdb_test "ptype s" \ > + [multi_line \ > + "type = <ref> new pck.shape with record" \ > + " r: integer;" \ > + "end record"] \ > + "ptype s, with debug info" > +} else { > + gdb_test "ptype s" \ > + [multi_line \ > + "type = <ref> tagged record" \ > + " x: integer;" \ > + " y: integer;" \ > + "end record" ] \ > + "ptype s, without debug info" > +} +1 for the use of multi_line here. Thanks Simon! > > -gdb_test "ptype s" \ > - "type = <ref> new pck.shape with record${eol}${sp}r: integer;${eol}end record" > diff --git a/gdb/testsuite/lib/ada.exp b/gdb/testsuite/lib/ada.exp > index 45c41806a648..378c0db610e4 100644 > --- a/gdb/testsuite/lib/ada.exp > +++ b/gdb/testsuite/lib/ada.exp > @@ -149,3 +149,39 @@ proc gnatmake_version_at_least { major } { > # Unknown, return 1 > return 1 > } > + > +# Return 1 if the GNAT runtime appears to have debug info. > + > +gdb_caching_proc gnat_runtime_has_debug_info { > + global srcdir > + > + set src "$srcdir/lib/gnat-debug-info-test.adb" > + set dst [standard_output_file "gnat-debug-info-test"] > + > + if { [gdb_compile_ada $src $dst executable {debug}] != "" } { > + fail "failed to compile gnat-debug-info test binary" > + return 0 > + } > + > + clean_restart $dst > + > + if { ! [runto "Hello"] } { > + fail "failed to run to Hello" > + return 0 > + } > + > + set has_debug_info 0 > + > + gdb_test_multiple "whatis __gnat_debug_raise_exception" "" { > + -re "type = <text variable, no debug info>" { } > + -re "type = void" { > + set has_debug_info 1 > + } > + default { > + # Some other unexpected output... > + fail $gdb_test_name > + } > + } > + > + return 0 I think you meant to return $has_debug_info here. Otherwise, running ptype_tagged_param.exp, I get a failure indicating that it tried to match the output thinking the runtime has no debug info. > diff --git a/gdb/testsuite/lib/gnat-debug-info-test.adb b/gdb/testsuite/lib/gnat-debug-info-test.adb > new file mode 100644 > index 000000000000..f1831ad86991 > --- /dev/null > +++ b/gdb/testsuite/lib/gnat-debug-info-test.adb > @@ -0,0 +1,6 @@ > +with Ada.Text_IO; > + > +procedure Hello is It's not absolutely crucial, but it is better if the name of the file matches the name of the unit. I would rename the file to something like gnat_debug_info_test.adb, and then change the name of the subprogram to GNAT_Debug_Info_Test. If the use of dashes was to avoid undercore characters, which are traditionally more efforts to type when on US keyboards, we can always drop those entirely... Other than that, the patch looks good to me.
On 2019-12-23 2:29 a.m., Joel Brobecker wrote: >> At first, I made it so we would XFAIL the test, in the absence of debug >> info, but then I thought that we might as well test for the output we >> expect in the absence of debug info instead. > > FWIW, I don't mind checking for the result that we get when the runtime > is missing the debugging information. The only downside I see is that > the expected behavior is less predictable: It depends on both > the implementation chosen by the compiler, which can change over time, > and also across targets, but can also depend on GDB's implementation > choices too. > > For my money, I think the most practical approach is to actually > say "this test requires debugging information from the runtime, > so if you do not have it, then the testcase cannot be run", in > which case we return UNSUPPORTED instead of returning an XFAIL > or changing the expected output. > > I like your approach because it forces us to test GDB more thouroughly, > and in particular it verifies the behavior when in degraded mode. > We should just be aware that this would be at the cost of some > occasional testcase maintenance work, when anything affecting > the somewhat unspecified outcome changes. I have a slight preference for testing GDB's actual behavior instead of just saying "unsupported", because if GDB's behavior changes by inadvertence, the test case will notify us and we can decide whether that change makes sense (and if so update the test case) or if it's actually a regression. If as you say, the output changes based on the compiler and the target, it won't be too hard to change the test to accept various outputs. Or if it's really too much trouble, I would maybe use something like: gdb_test "ptype s" ".*" which would ensure at least that GDB doesn't crash when issuing this command without debug info available. >> diff --git a/gdb/testsuite/lib/ada.exp b/gdb/testsuite/lib/ada.exp >> index 45c41806a648..378c0db610e4 100644 >> --- a/gdb/testsuite/lib/ada.exp >> +++ b/gdb/testsuite/lib/ada.exp >> @@ -149,3 +149,39 @@ proc gnatmake_version_at_least { major } { >> # Unknown, return 1 >> return 1 >> } >> + >> +# Return 1 if the GNAT runtime appears to have debug info. >> + >> +gdb_caching_proc gnat_runtime_has_debug_info { >> + global srcdir >> + >> + set src "$srcdir/lib/gnat-debug-info-test.adb" >> + set dst [standard_output_file "gnat-debug-info-test"] >> + >> + if { [gdb_compile_ada $src $dst executable {debug}] != "" } { >> + fail "failed to compile gnat-debug-info test binary" >> + return 0 >> + } >> + >> + clean_restart $dst >> + >> + if { ! [runto "Hello"] } { >> + fail "failed to run to Hello" >> + return 0 >> + } >> + >> + set has_debug_info 0 >> + >> + gdb_test_multiple "whatis __gnat_debug_raise_exception" "" { >> + -re "type = <text variable, no debug info>" { } >> + -re "type = void" { >> + set has_debug_info 1 >> + } >> + default { >> + # Some other unexpected output... >> + fail $gdb_test_name >> + } >> + } >> + >> + return 0 > > I think you meant to return $has_debug_info here. Otherwise, > running ptype_tagged_param.exp, I get a failure indicating that > it tried to match the output thinking the runtime has no debug > info. Eh, of course! >> diff --git a/gdb/testsuite/lib/gnat-debug-info-test.adb b/gdb/testsuite/lib/gnat-debug-info-test.adb >> new file mode 100644 >> index 000000000000..f1831ad86991 >> --- /dev/null >> +++ b/gdb/testsuite/lib/gnat-debug-info-test.adb >> @@ -0,0 +1,6 @@ >> +with Ada.Text_IO; >> + >> +procedure Hello is > > It's not absolutely crucial, but it is better if the name of > the file matches the name of the unit. I would rename the file > to something like gnat_debug_info_test.adb, and then change > the name of the subprogram to GNAT_Debug_Info_Test. > > If the use of dashes was to avoid undercore characters, which are > traditionally more efforts to type when on US keyboards, we can > always drop those entirely... Haha, no, my choices were due to my ignorance of the good practices when using Ada. I applied your suggestions. > Other than that, the patch looks good to me. Thanks for the review. I ended up downloading GNAT from https://www.adacore.com/download which lets me test the "with debug info" case, and confirm that it now works, so I pushed the patch with the changes mentioned above. Simon
diff --git a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp index 567ef8251d9f..87a676c9ca24 100644 --- a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp +++ b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp @@ -21,14 +21,28 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } return -1 } +set has_runtime_debug_info [gnat_runtime_has_debug_info] + clean_restart ${testfile} if ![runto "position_x" ] then { return -1 } -set eol "\[\r\n\]+" -set sp "\[ \t\]*" +if { $has_runtime_debug_info } { + gdb_test "ptype s" \ + [multi_line \ + "type = <ref> new pck.shape with record" \ + " r: integer;" \ + "end record"] \ + "ptype s, with debug info" +} else { + gdb_test "ptype s" \ + [multi_line \ + "type = <ref> tagged record" \ + " x: integer;" \ + " y: integer;" \ + "end record" ] \ + "ptype s, without debug info" +} -gdb_test "ptype s" \ - "type = <ref> new pck.shape with record${eol}${sp}r: integer;${eol}end record" diff --git a/gdb/testsuite/lib/ada.exp b/gdb/testsuite/lib/ada.exp index 45c41806a648..378c0db610e4 100644 --- a/gdb/testsuite/lib/ada.exp +++ b/gdb/testsuite/lib/ada.exp @@ -149,3 +149,39 @@ proc gnatmake_version_at_least { major } { # Unknown, return 1 return 1 } + +# Return 1 if the GNAT runtime appears to have debug info. + +gdb_caching_proc gnat_runtime_has_debug_info { + global srcdir + + set src "$srcdir/lib/gnat-debug-info-test.adb" + set dst [standard_output_file "gnat-debug-info-test"] + + if { [gdb_compile_ada $src $dst executable {debug}] != "" } { + fail "failed to compile gnat-debug-info test binary" + return 0 + } + + clean_restart $dst + + if { ! [runto "Hello"] } { + fail "failed to run to Hello" + return 0 + } + + set has_debug_info 0 + + gdb_test_multiple "whatis __gnat_debug_raise_exception" "" { + -re "type = <text variable, no debug info>" { } + -re "type = void" { + set has_debug_info 1 + } + default { + # Some other unexpected output... + fail $gdb_test_name + } + } + + return 0 +} diff --git a/gdb/testsuite/lib/gnat-debug-info-test.adb b/gdb/testsuite/lib/gnat-debug-info-test.adb new file mode 100644 index 000000000000..f1831ad86991 --- /dev/null +++ b/gdb/testsuite/lib/gnat-debug-info-test.adb @@ -0,0 +1,6 @@ +with Ada.Text_IO; + +procedure Hello is +begin + Ada.Text_IO.Put_Line("Hello, world!"); +end Hello;