public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
@ 2023-01-19 16:31 Tom Tromey
  2023-01-20 17:00 ` Simon Marchi
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2023-01-19 16:31 UTC (permalink / raw)
  To: gdb-patches; +Cc: Tom Tromey

gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
However, it's actually generating the correct output -- it is just
that the test thinks that the "ptype" will not work because I do not
have the GNAT debuginfo installed.

This patch changes the code to accept either result, and then to issue
a kfail as appropriate.
---
 gdb/testsuite/gdb.ada/ptype_tagged_param.exp | 42 +++++++++++---------
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp
index 0050d60a0f2..eaf61ddde79 100644
--- a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp
+++ b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp
@@ -31,23 +31,27 @@ if {![runto "pck.adb:20"]} {
   return -1
 }
 
-# Identifying the runtime type of S can only be done when we have the debug
-# info for the GNAT runtime.
-
-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"
+# With some versions of the compiler, identifying the runtime type of
+# S can only be done when we have the debug info for the GNAT runtime.
+set ordinary [multi_line \
+		  "type = <ref> new pck.shape with record" \
+		  "    r: integer;" \
+		  "end record"]
+set nodebug [multi_line \
+		 "type = <ref> tagged record" \
+		 "    x: integer;" \
+		 "    y: integer;" \
+		 "end record"]
+
+gdb_test_multiple "ptype s" "ptype s" {
+    -re -wrap $ordinary {
+	pass $gdb_test_name
+    }
+    -re -wrap $nodebug {
+	if {$has_runtime_debug_info} {
+	    kfail "no debug info" $gdb_test_name
+	} else {
+	    fail $gdb_test_name
+	}
+    }
 }
-
-- 
2.38.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-19 16:31 [PATCH] Make gdb.ada/ptype_tagged_param.exp pass Tom Tromey
@ 2023-01-20 17:00 ` Simon Marchi
  2023-01-20 17:05   ` Tom Tromey
  0 siblings, 1 reply; 7+ messages in thread
From: Simon Marchi @ 2023-01-20 17:00 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches



On 1/19/23 11:31, Tom Tromey via Gdb-patches wrote:
> gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
> However, it's actually generating the correct output -- it is just
> that the test thinks that the "ptype" will not work because I do not
> have the GNAT debuginfo installed.
> 
> This patch changes the code to accept either result, and then to issue
> a kfail as appropriate.

I introduced that code in 2019, saying:

    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.

However, now, on the same system (but obviously not the same package
versions, as I keep it up to date), I see the same as you:

    (gdb) ptype s
    type = <ref> new pck.shape with record
        r: integer;
    end record
    (gdb) FAIL: gdb.ada/ptype_tagged_param.exp: ptype s, without debug info

Do you know what could have changed?  New improved DWARF info from a
newer compiler?

In any case, your change LGTM, since it will still cause a fail if we do
have debug info but see the bad output.

Simon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-20 17:00 ` Simon Marchi
@ 2023-01-20 17:05   ` Tom Tromey
  2023-01-27  5:58     ` Simon Marchi
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2023-01-20 17:05 UTC (permalink / raw)
  To: Simon Marchi via Gdb-patches; +Cc: Tom Tromey, Simon Marchi

>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:

Simon> Do you know what could have changed?  New improved DWARF info from a
Simon> newer compiler?

Possibly, but I don't really know, and I actually don't remember all
that much about how tagged types work under the hood.

Simon> In any case, your change LGTM, since it will still cause a fail if we do
Simon> have debug info but see the bad output.

Thanks, I'm going to check it in.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-20 17:05   ` Tom Tromey
@ 2023-01-27  5:58     ` Simon Marchi
  2023-01-27 14:11       ` Tom Tromey
  0 siblings, 1 reply; 7+ messages in thread
From: Simon Marchi @ 2023-01-27  5:58 UTC (permalink / raw)
  To: Tom Tromey, Simon Marchi via Gdb-patches

On 1/20/23 12:05, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Simon> Do you know what could have changed?  New improved DWARF info from a
> Simon> newer compiler?
> 
> Possibly, but I don't really know, and I actually don't remember all
> that much about how tagged types work under the hood.
> 
> Simon> In any case, your change LGTM, since it will still cause a fail if we do
> Simon> have debug info but see the bad output.
> 
> Thanks, I'm going to check it in.
> 
> Tom

Woops, I hit a FAIL here.  I think the $has_runtime_debug_info condition
is backwards

Simon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-27  5:58     ` Simon Marchi
@ 2023-01-27 14:11       ` Tom Tromey
  2023-01-27 15:56         ` Simon Marchi
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2023-01-27 14:11 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Tom Tromey, Simon Marchi via Gdb-patches

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> Woops, I hit a FAIL here.  I think the $has_runtime_debug_info condition
Simon> is backwards

I can check in a patch to flip this if you think that will help.  I have
no way to test it, though.  I tried installing and removing the relevant
debuginfo packages on my machine, but the test works either way for me.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-27 14:11       ` Tom Tromey
@ 2023-01-27 15:56         ` Simon Marchi
  2023-01-27 17:24           ` Tom Tromey
  0 siblings, 1 reply; 7+ messages in thread
From: Simon Marchi @ 2023-01-27 15:56 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Simon Marchi via Gdb-patches

On 1/27/23 09:11, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> Woops, I hit a FAIL here.  I think the $has_runtime_debug_info condition
> Simon> is backwards
> 
> I can check in a patch to flip this if you think that will help.  I have
> no way to test it, though.  I tried installing and removing the relevant
> debuginfo packages on my machine, but the test works either way for me.

So, the current code is:


 50     -re -wrap $nodebug {
 51         if {$has_runtime_debug_info} {
 52             kfail "no debug info" $gdb_test_name
 53         } else {
 54             fail $gdb_test_name
 55         }
 56     }

This says: if we receive the wrong output, and we have GNAT debug info,
this is expected.  I think it's wrong, it should be: if we receive the
wrong output and we _don't_ have debug info, this is expected.

I see this on Ubuntu 22.04, with the gnat-11 package installed.  Without
libgnat-11-dbgsym, I get:

(gdb) ptype s
type = <ref> tagged record
    x: integer;
    y: integer;
end record
(gdb) FAIL: gdb.ada/ptype_tagged_param.exp: ptype s

And with libgnat-11-dbgsym installed:

type = <ref> new pck.shape with record
    r: integer;
end record
(gdb) PASS: gdb.ada/ptype_tagged_param.exp: ptype s

If I flip the condition to what I think makes more sense, the former
(without libgnat-11-dbgsym) case becomes:

type = <ref> tagged record
    x: integer;
    y: integer;
end record
(gdb) KFAIL: gdb.ada/ptype_tagged_param.exp: ptype s (PRMS: no debug info)

And the "with libgnat-11-dbgsym" case still passes fine, since it
outputs the right thing.

Simon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Make gdb.ada/ptype_tagged_param.exp pass
  2023-01-27 15:56         ` Simon Marchi
@ 2023-01-27 17:24           ` Tom Tromey
  0 siblings, 0 replies; 7+ messages in thread
From: Tom Tromey @ 2023-01-27 17:24 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Tom Tromey, Simon Marchi via Gdb-patches

Simon> This says: if we receive the wrong output, and we have GNAT debug info,
Simon> this is expected.  I think it's wrong, it should be: if we receive the
Simon> wrong output and we _don't_ have debug info, this is expected.

Thank.  I'm going to send the fix & check it in.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-01-27 17:24 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-19 16:31 [PATCH] Make gdb.ada/ptype_tagged_param.exp pass Tom Tromey
2023-01-20 17:00 ` Simon Marchi
2023-01-20 17:05   ` Tom Tromey
2023-01-27  5:58     ` Simon Marchi
2023-01-27 14:11       ` Tom Tromey
2023-01-27 15:56         ` Simon Marchi
2023-01-27 17:24           ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).