Backport "Fix assertion failure in copy_type"

Resolves: rhbz#2155439
This commit is contained in:
Bruno Larsen 2023-03-22 16:04:39 +01:00
parent dfc42b6533
commit 7bad2de11f
6 changed files with 162 additions and 0 deletions

View File

@ -463,3 +463,11 @@ Patch111: gdb-rhbz1870017-p10-plt-prologue-skipping.patch
# (Simon Marchi, RHBZ 2086761)
Patch112: gdb-rhbz2086761-unknown-cfa-rule.patch
# Backport "Fix assertion failure in copy_type"
# (Tom Tromey, RHBZ2155439)
Patch113: gdb-rhbz2155439-assert-failure-copy_type.patch
# Backport "[gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp"
# (Tom de Vries)
Patch114: gdb-fix-gdb.base-printcmds-s390x-regressions.patch

View File

@ -110,3 +110,5 @@
%patch110 -p1
%patch111 -p1
%patch112 -p1
%patch113 -p1
%patch114 -p1

View File

@ -110,3 +110,5 @@ gdb-rhbz2012819-ibmz-update-4of5.patch
gdb-rhbz2012819-ibmz-update-5of5.patch
gdb-rhbz1870017-p10-plt-prologue-skipping.patch
gdb-rhbz2086761-unknown-cfa-rule.patch
gdb-rhbz2155439-assert-failure-copy_type.patch
gdb-fix-gdb.base-printcmds-s390x-regressions.patch

View File

@ -0,0 +1,71 @@
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 12 Dec 2022 15:21:33 +0100
Subject: gdb-fix-gdb.base-printcmds-s390x-regressions.patch
;; Backport "[gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp"
;; (Tom de Vries)
On s390x-linux, I run into:
...
(gdb) print {unsigned char}{65}^M
$749 = 0 '\000'^M
(gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
...
In contrast, on x86_64-linux, we have:
...
(gdb) print {unsigned char}{65}^M
$749 = 65 'A'^M
(gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
...
The first problem here is that the test is supposed to be a regression test
for PR20630, which can be reproduced (for an unfixed gdb) like this:
...
(gdb) p {unsigned char[]}{0x17}
gdbtypes.c:4641: internal-error: copy_type: \
Assertion `TYPE_OBJFILE_OWNED (type)' failed.
...
but it's not due to insufficient quoting (note the dropped '[]').
That's easy to fix, but after that we have on s390 (big endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = ""^M
...
and on x86_64 (little endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = "A"^M
...
Fix this by using 0xffffffff, such that in both cases we have:
...
(gdb) print {unsigned char[]}{0xffffffff}^M
$749 = "\377\377\377\377"^M
...
Tested on x86_64-linux and s390x-linux.
diff --git a/gdb/testsuite/gdb.base/printcmds.exp b/gdb/testsuite/gdb.base/printcmds.exp
--- a/gdb/testsuite/gdb.base/printcmds.exp
+++ b/gdb/testsuite/gdb.base/printcmds.exp
@@ -717,6 +717,7 @@ proc test_print_string_constants {} {
}
proc test_print_array_constants {} {
+ global hex
if [target_info exists gdb,cannot_call_functions] {
unsupported "this target can not call functions"
@@ -735,7 +736,8 @@ proc test_print_array_constants {} {
gdb_test "print *&{4,5,6}\[1\]" "Attempt to take address of value not located in memory."
# This used to cause a crash.
- gdb_test "print {unsigned char[]}{65}" " = 65 'A'"
+ set val [string_to_regexp {"\377\377\377\377"}]
+ gdb_test "print {unsigned char\[\]}{0xffffffff}" " = $val"
}
proc test_print_enums {} {

View File

@ -0,0 +1,73 @@
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
From: Bruno Larsen <blarsen@redhat.com>
Date: Wed, 22 Mar 2023 15:48:00 +0100
Subject: gdb-rhbz2155439-assert-failure-copy_type.patch
;; Backport "Fix assertion failure in copy_type"
;; (Tom Tromey, RHBZ2155439)
PR exp/20630 points out a simple way to cause an assertion failure in
copy_type -- but this was found in the wild a few times as well.
copy_type only works for objfile-owned types, but there isn't a deep
reason for this. This patch fixes the bug by updating copy_type to
work for any sort of type.
Better would perhaps be to finally implement type GC, but I still
haven't attempted this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20630
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -5504,27 +5504,24 @@ copy_type_recursive (struct objfile *objfile,
}
/* Make a copy of the given TYPE, except that the pointer & reference
- types are not preserved.
-
- This function assumes that the given type has an associated objfile.
- This objfile is used to allocate the new type. */
+ types are not preserved. */
struct type *
copy_type (const struct type *type)
{
- struct type *new_type;
-
- gdb_assert (TYPE_OBJFILE_OWNED (type));
-
- new_type = alloc_type_copy (type);
+ struct type *new_type = alloc_type_copy (type);
TYPE_INSTANCE_FLAGS (new_type) = TYPE_INSTANCE_FLAGS (type);
TYPE_LENGTH (new_type) = TYPE_LENGTH (type);
memcpy (TYPE_MAIN_TYPE (new_type), TYPE_MAIN_TYPE (type),
sizeof (struct main_type));
if (type->main_type->dyn_prop_list != NULL)
- new_type->main_type->dyn_prop_list
- = copy_dynamic_prop_list (&TYPE_OBJFILE (type) -> objfile_obstack,
- type->main_type->dyn_prop_list);
+ {
+ struct obstack *storage = (TYPE_OBJFILE_OWNED (type)
+ ? &TYPE_OBJFILE (type)->objfile_obstack
+ : gdbarch_obstack (TYPE_OWNER (type).gdbarch));
+ new_type->main_type->dyn_prop_list
+ = copy_dynamic_prop_list (storage, type->main_type->dyn_prop_list);
+ }
return new_type;
}
diff --git a/gdb/testsuite/gdb.base/printcmds.exp b/gdb/testsuite/gdb.base/printcmds.exp
--- a/gdb/testsuite/gdb.base/printcmds.exp
+++ b/gdb/testsuite/gdb.base/printcmds.exp
@@ -733,6 +733,9 @@ proc test_print_array_constants {} {
gdb_test_escape_braces "print {{0,1,2},{3,4,5}}" " = {{0, 1, 2}, {3, 4, 5}}"
gdb_test "print {4,5,6}\[2\]" " = 6"
gdb_test "print *&{4,5,6}\[1\]" "Attempt to take address of value not located in memory."
+
+ # This used to cause a crash.
+ gdb_test "print {unsigned char[]}{65}" " = 65 'A'"
}
proc test_print_enums {} {

View File

@ -1158,6 +1158,12 @@ fi
%endif
%changelog
* Wed Mar 23 2023 Bruno Larsen <blarsen@redhat.com>
- Bakport "Fix assertion failure in copy_type"
(Tom Tromey, RHBZ 2155439)
- Bakport "[gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp"
(Tom de Vries)
* Tue May 24 2022 Keith Seitz <keiths@redhat.com> - 10.2-10.el9
- Backport "fix logic of find_comp_unit and set_comp_unit"
(Simon Marchi, RHBZ 2086761)