From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by sourceware.org (Postfix) with ESMTPS id BC1D53858289 for ; Tue, 11 Oct 2022 08:03:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC1D53858289 X-IronPort-AV: E=McAfee;i="6500,9779,10496"; a="303179351" X-IronPort-AV: E=Sophos;i="5.95,175,1661842800"; d="scan'208";a="303179351" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2022 01:03:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10496"; a="730883261" X-IronPort-AV: E=Sophos;i="5.95,175,1661842800"; d="scan'208";a="730883261" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga002.fm.intel.com with ESMTP; 11 Oct 2022 01:03:48 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 11 Oct 2022 01:03:47 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 11 Oct 2022 01:03:47 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Tue, 11 Oct 2022 01:03:47 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.174) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Tue, 11 Oct 2022 01:03:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FQfkjocQJDRHq6OCC5f9K6BGoL3tQtvS2N38EeIbzg6nNkAGaqVPtPGtFScvhf1rwBV//+NJUYyZ8YC3qAreOsUWfVvvcyj68PzjNCi4t+94yNe3kugHI1S/g/j/DCYoFyDcyy2BeM0mD3SSJVeqx1elZRdoUvPHxa7NXgaAv4JEi9asqYo4YQ4iRtIAeDOVsmSyyDT72Fr1n+j2P78BchLlfIhk2esVz53Zhh0/NUQNF3a0eSMmmE3TR4dN8UiSs1UYx/y7MxKfWPnet6ssGG25wrb+35mwLPf89hJXdrZoeBml+FLevx3GwtKhAzSYnY6lD/yqZ3WJnPG8X5vjnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/efyA1B0v7rqCqTGtZ6Wqk2DoHtG+jigGAZDGszcZN8=; b=BJYko83GSz0RLpVRUQLOf/lJyujONh5OWgmS9yEBPfLPJzXZWkfkpIbAAm+rV0JC66SnwabOcRAe/Decj3nPK080vaabADht9nxZur0eheO9/wpLVecsA/T1yp8YBCYllIZvTIFYBqynYGtio/29akvM+eargWk/C7OlRSUDZ7OBLpTyWAFCsVluRa6gK/CAkTAl79FFdVMextdcRHGyeAuWRm/iNhV1VYg2jhOI+rBtkxWDH682yAkXA2RLEtXbvyGxDqnMQoXpe4HyAU4J3UCL0luluupqFQLabObfUsUYndRlwZ4z8l5fTraxPMWQYqPUtl/uyeiMEofCzP9Osg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM6PR11MB4564.namprd11.prod.outlook.com (2603:10b6:5:2a0::7) by SA2PR11MB5209.namprd11.prod.outlook.com (2603:10b6:806:110::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.19; Tue, 11 Oct 2022 08:03:45 +0000 Received: from DM6PR11MB4564.namprd11.prod.outlook.com ([fe80::8181:3581:a80:189f]) by DM6PR11MB4564.namprd11.prod.outlook.com ([fe80::8181:3581:a80:189f%9]) with mapi id 15.20.5709.021; Tue, 11 Oct 2022 08:03:45 +0000 From: "Rohr, Stephan" To: Simon Marchi , "gdb-patches@sourceware.org" CC: "tom@tromey.com" Subject: RE: [PATCH 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type. Thread-Topic: [PATCH 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type. Thread-Index: AQHYVld/d1fm2wYrDkmpYy79VGQNmq23J+KAgFEVwHA= Date: Tue, 11 Oct 2022 08:03:45 +0000 Message-ID: References: <20220422144420.3545190-1-stephan.rohr@intel.com> <20220422144420.3545190-2-stephan.rohr@intel.com> <0895de32-0b1b-4053-7a90-21d12fe81b6a@simark.ca> In-Reply-To: <0895de32-0b1b-4053-7a90-21d12fe81b6a@simark.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: dlp-product: dlpe-windows dlp-version: 11.6.500.17 dlp-reaction: no-action x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR11MB4564:EE_|SA2PR11MB5209:EE_ x-ms-office365-filtering-correlation-id: de7a9ea5-3340-41a5-36ed-08daab5f1ea3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7jxgdRiVCabvr3abpYI/9rBZ1tvpR6jqrTlte0587ptLGDvLJb0Ba/sL4I5e2MyhpVo4nVbRjugTQqJ55I4Rzk6zw0dUEFYOg6bS5lxgklXR78g5+FHLdKALE7LXKVshHddLsYhwt6TUm3lQCxaELXnulkw8wLsf/L52L31mh+KXtTX9Q+WFZB8cvDpLVtX/P2DTlAyzyINpoIWmOgbzGJ1GooA6Cyrkyg3jzXwqcu/aQffuC5mOJ5NA36P5hXu9Swx7qinF27eL0UjEuTMn/AsA7KX/8KeDgjc52RIyfy1LGGYAW9nc1wXxOWV53RUAF3k44riCXFPuVRmHAHC5mA88dAjBA+oZl4mlHpVYELbTUCEhj7qJK6YbMddrIx9WBLDWW0remf2Rbh4pNey/+RaI5lDkSSaGJXSNEFMok2kTDXQ92RQPxZT1QEHcdun0bPq8Oh3RcIfrV8RRQHpEjGz6Jg58Oxq2h3oleRDe48SUSU2QzJx17RGPeK5I4qPQgRRENC/EkNfCf1FXyC5WqWujByZHI1Uogm81miQc2/7UUX/Pv+9hc10jz5Sedo87CZCef1C+0aLm8uQam9GUWcKGOzmFrFXiz3FmVBajpT/7sGB4a6bbsrTYo1ldNstZVtv37uHDfzspACeoxQRhn83Z5bKJXBGiao0qAJSxU+uOgSogRWJRdBFeCAP2zUBSUIZexWvb1dmKNzb3ciLDsOHCdLccwVdtnCl0nPRt5dFfYbbyY5neterNHZQB2mykXXc7k57cSMhpShUDoMpynglKiZtKwwKVVdg7B+OceOw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4564.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(366004)(376002)(346002)(39860400002)(396003)(451199015)(9686003)(2906002)(83380400001)(110136005)(55016003)(478600001)(33656002)(53546011)(71200400001)(6506007)(26005)(5660300002)(8936002)(52536014)(7696005)(122000001)(82960400001)(38070700005)(186003)(76116006)(38100700002)(86362001)(64756008)(316002)(66476007)(66446008)(66556008)(66946007)(4326008)(966005)(8676002)(41300700001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kbmGZhCpplj+0Y8weUZhy82O8ySckW/37llwPgxtVabeN3aoyZtuxYtvWq3V?= =?us-ascii?Q?oDTRSDmX4aRc7U+WYjKU7Ym51oDZ7lX/RvY5C3KlDmbuQxP63TZkIGMEdpiZ?= =?us-ascii?Q?KDlIvCUIDt1duIOCLL+ChKHylW/GOonILlWV2paJb5W3wbTKI0x65aeXxtwu?= =?us-ascii?Q?zBWezlrkElbrdJYDJyDpdzVWXGdEoIT0DwjpIqrFf57zk8a5zLQZF8FFE9bI?= =?us-ascii?Q?w7N4ThhSPLi+u6aHRqXWUhHvBLgGI5kzXiRbFEVg5GvvCeIOMyznmkS7oV+M?= =?us-ascii?Q?OX/cB4g/xb3cjgFjVZnUyQ+UA9X3o5KbHdImNI5Y3U5s7C1OHGAYOt4aUXQ/?= =?us-ascii?Q?xeUXBHVTHAKVBZGLF94sIdbuUrp5RgBEeMg5vMbTgm9eingpIcycF5QII4ba?= =?us-ascii?Q?3jzjVv0LoL0D1GM+v7YRI+HhHTlNCLOaVn8Pgqnpfm6c8fLGnDNY4Ju4m4EI?= =?us-ascii?Q?qVohkt3HfPD4ww6s1r+0nAAfBmGph7JdckmvL7EpKikLcDSD5GkFWewGkzlq?= =?us-ascii?Q?UOTlaT8oMh77Ck7yNAKK0B+gxlK8rzE/T4OVJOlb/oLjH5QtYdEc/cX6/nt7?= =?us-ascii?Q?hknBgcPvPfrd2XvnakXUdvvncM3XN6m2PGSFKcGugeCIdpfoaOXwQ9wMnIKb?= =?us-ascii?Q?/Q2e2+qxNPWZKG+D6u+CgJy2AWc7rEjONfZWDaPFDVFhgA8M6UIycPKbPHKT?= =?us-ascii?Q?P0MWLbYhWh2s4A/VApMrPQVLAmkCfHQtL+as/To8HY3M+oNQbjt64lm5gnxq?= =?us-ascii?Q?QjEWMwvRPzTAV8P7sXABrrbQWykGuu/Q8/sP9QMjtunSv9/p/8G2QiuTN3N9?= =?us-ascii?Q?f+K6czuaNJxkTV3clOPTu0yqbCG7SaeTBSM5Xcw89WoDpmeK7SqkClaNzY6P?= =?us-ascii?Q?BbEBU/rJlWow/9ZjUflQTz5AoaCETruM/aSWUsNpk/1/cZZCHENoJYeM9VWn?= =?us-ascii?Q?VkFg36eEWvEuRZM3s/m0VAC/cDHPDbZduwXdO8+AbmyetqxBTTCIM4P8RBc1?= =?us-ascii?Q?NQh9V3rO2PH1wjK78Tx1eUdAJifl46K43ad9WOwy26zL8aisqMiNtBzyLJa/?= =?us-ascii?Q?HHEwO/vlaa4LaL1U3plya6XxGKuLjjAf6r5YPxDwfdkvMcsfD5rdCsDsgJip?= =?us-ascii?Q?Es5dsOTait20rVpfmLpdSWLs2GXr0RV3LCkqVQr7yGSofhjhFsKZBVBGUUVF?= =?us-ascii?Q?A/MnkZxgr8itP5/W5Q+NJ5xndfSNnyWKayri308n8XOrvI6eWqdswYQcKkfu?= =?us-ascii?Q?do3sZoITDSAZiVBmxthvXimON1BZ7agOzQ93PzWMJX9pbAZyBSiCmVxp3z6C?= =?us-ascii?Q?XFkY8Vphx52H7HZToDWAp2RTlknqNPjO+Cn8Rf7UBLxcqt12A30PpbEjLbAz?= =?us-ascii?Q?F64Q+Ul6DQe8ApzhradkmSxeGDKSoUnzqKbX11l1X/Zj4bDxGLivOpLgjORY?= =?us-ascii?Q?4gPeOJxKeWAYe3T0TzpT7SrOMpmeZUb9Hg6isXxFh1nUKZl1eOUBU4LxuMMK?= =?us-ascii?Q?R+YbRGdn8KekNGGn6Nve5hlPgD3o8mv24YJFJGbOPlIX/5aUJyYE8gJ12UQh?= =?us-ascii?Q?tgj3xuPBjpTXfxaK6xdamuCSqG2TwzrYe+o3fW7i?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4564.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de7a9ea5-3340-41a5-36ed-08daab5f1ea3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2022 08:03:45.0446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q/OpSkAZp+YN/3YKoOqnnBV112FuOc7qwKoKerM2CJLc6pN6UK/cYXnKtpZpW35CysZqOYCe/NUYzedpP8RMpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB5209 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, 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 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: Tue, 11 Oct 2022 08:03:55 -0000 Hi Simon, thanks for the feedback and sorry for the late reply. Please see my answer= s below. > -----Original Message----- > From: Simon Marchi > Sent: Friday, August 19, 2022 6:40 PM > To: Rohr, Stephan ; gdb-patches@sourceware.org > Cc: tom@tromey.com > Subject: Re: [PATCH 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values cas= ted > to different type. > = > On 4/22/22 10:44, Stephan Rohr via Gdb-patches wrote: > > From: "Rohr, Stephan" > > > > The 'rw_pieced_value' function is executed when fetching a (lazy) > > variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The > > function checks the 'type' and 'enclosing_type' fields of the value > > for identity. > > > > * The 'type' field describes the type of a value. > > * In most cases, the 'enclosing_type' field is identical to the > > 'type' field. > > * Scenarios where the 'type' and 'enclosing_type' of an object > > differ are described in 'gdb/value.c'. Possible cases are: > > * If a value represents a C++ object, then the 'type' field > > gives the object's compile-time type. If the object actually > > belongs to some class derived from `type', perhaps with other > > base classes and additional members, then `type' is just a > > subobject of the real thing, and the full object is probably > > larger than `type' would suggest. > > * If 'type' is a dynamic class (i.e. one with a vtable), then GDB > > can actually determine the object's run-time type by looking at > > the run-time type information in the vtable. GDB may then elect > > to read the entire object. > > * If the user casts a variable to a different type > > (e.g. 'print ( []) '), the value's type is > > updated before reading the value. > = > Out of curiosity, where do you see these scenarios described? I could not > find where value.c talks about the case where the user casts the variable. > = This scenario is not described in value.c. The issue came up in our test s= uite where the assertion caused GDB to crash when casting a pieced value, e.g., (gdb) info address a Symbol "a" is multi-location: Range 0xfffd5990-0xfffd5e50: a variable in $r68 [256-bit piece, offset 0 = bits], and a variable in $r69 [256-bit piece, offset 0 bits], ... (gdb) pt a type =3D double [16][4] (gdb) p (double[])a .../gdb/dwarf2/loc.c:1771: internal-error: Should not be able to create a l= azy value with an enclosing type A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) > > > > If a lazy value is fetched, GDB allocates space based on the enclosing > > type's length and typically reads the 'full' object. > > This is not implemented for pieced values and causes an internal error > > if 'type' and 'enclosing_type' of a value are not identical. > > > > However, GDB can read the value based on its type. Thus, it should be > > sufficient to check if the type's length (potentially shifted by > > 'embedded_offset') does not exceed the enclosing type's length which > > was used for memory allocation. > = > I'm trying to understand a bit better what happens here. The current > assertion states that it's incorrect to have a lazy value where the type = does > not match the enclosing_type (I don't really know why), but it clearly > happens here. So I'd like to determine who's right, the assertion or the= code > that produces such a value. For reference, the assertion was added here: > = > https://pi.simark.ca/gdb-patches/m3hbmbviko.fsf@fleche.redhat.com/#t > = I contacted Tom when I first encountered this issue. Based on his feedback, it seems fine to remove the assertion if the results work correctly. With = your feedback and the test cases I added, I would agree that we can remove the original assertion, though I also don't know why it was originally added. > I was wondering at which point exactly we end up with such a value. > It's here that we assign a new type (the array type) to the value, while = the > value is lazy, when handling the value cast: > = > #0 deprecated_set_value_type (value=3D0x61100020a700, > type=3D0x621000506890) at /home/smarchi/src/binutils-gdb/gdb/value.c:1105 > #1 0x0000564249d99092 in value_cast (type=3D0x621000506730, > arg2=3D0x61100020a700) at /home/smarchi/src/binutils-gdb/gdb/valops.c:496 > #2 0x000056424838294c in expr::var_value_operation::evaluate_for_cast > (this=3D0x6030002a6220, to_type=3D0x621000506730, exp=3D0x60300011cbc0, > noside=3DEVAL_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/eval.c:2885 > #3 0x0000564247412e1e in expr::unop_cast_type_operation::evaluate > (this=3D0x6030002a6250, expect_type=3D0x0, exp=3D0x60300011cbc0, > noside=3DEVAL_NORMAL) at /home/smarchi/src/binutils- > gdb/gdb/expop.h:2036 > #4 0x000056424836092c in expression::evaluate (this=3D0x60300011cbc0, > expect_type=3D0x0, noside=3DEVAL_NORMAL) at /home/smarchi/src/binutils- > gdb/gdb/eval.c:101 > #5 0x0000564248360a9d in evaluate_expression (exp=3D0x60300011cbc0, > expect_type=3D0x0) at /home/smarchi/src/binutils-gdb/gdb/eval.c:115 > #6 0x0000564248e56c95 in process_print_command_args > (args=3D0x60200006fb52 "(int []) s1", print_opts=3D0x7ffe0fb62200, > voidprint=3Dtrue) at /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1307 > #7 0x0000564248e56e79 in print_command_1 (args=3D0x60200006fb52 "(int > []) s1", voidprint=3D1) at /home/smarchi/src/binutils-gdb/gdb/printcmd.c:= 1320 > #8 0x0000564248e57d15 in print_command (exp=3D0x60200006fb52 "(int [= ]) > s1", from_tty=3D1) at /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1453 > = > Meanwhile, the enclosing_type remains the original struct type. > = > So my question is: when doing the value cast, do we also want to overwrite > the value's enclosing type, in addition to the value's type? > Is it useful to retain the original enclosing type? In other words, we c= ould do > this change to also set the enclosing type when casting: > = > = > diff --git a/gdb/valops.c b/gdb/valops.c index 27e84d9f6b3..cb3fb49e50d > 100644 > --- a/gdb/valops.c > +++ b/gdb/valops.c > @@ -493,10 +493,10 @@ value_cast (struct type *type, struct value *arg2) > TYPE_TARGET_TYPE (range_= type), > low_bound, > new_length + low_bound -= 1); > - deprecated_set_value_type (arg2, > - create_array_type (NULL, > - element_type, > - range_type)); > + struct type *new_type > + =3D create_array_type (NULL, element_type, range_type); > + deprecated_set_value_type (arg2, new_type); > + set_value_enclosing_type (arg2, new_type); > return arg2; > } > } > = > I don't know if that change causes other things to fail, and I really don= 't know > what the answer is. This would surely fix the original issue I encountered. However, I also se= e the risk of unexpected side effects. > One case I wonder about is when the size of the original object is not a > multiple of the array's element size. For instance, imagine s1 is 9 byte= s long > and you do: > = > (gdb) print (int []) s1 > = > where an int is 4 bytes. The pieces of s1 will still describe 9 bytes, b= ut the > type and enclosing type will be 8 bytes long. That might be a problem do= wn > the road, and a reason we want to keep the original enclosing type whose > length matches the described content length. Some additional tests for t= hat > would be nice. > = I extended the shortpiece.exp testcase by adding another variable s3 that i= s 10 bytes long. GDB emits a warning and prints the maximum number of integers: p (int []) s3 warning: array element type size does not divide object size in cast $5 =3D {0, 1} This is expected and correct behavior from my point of view. > > --- > > gdb/dwarf2/expr.c | 6 ++---- > > gdb/testsuite/gdb.dwarf2/shortpiece.exp | 12 ++++++++++++ > > 2 files changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/gdb/dwarf2/expr.c b/gdb/dwarf2/expr.c index > > 99862583336..6330a5787fc 100644 > > --- a/gdb/dwarf2/expr.c > > +++ b/gdb/dwarf2/expr.c > > @@ -174,10 +174,8 @@ rw_pieced_value (value *v, value *from, bool > check_optimized) > > } > > else > > { > > - if (value_type (v) !=3D value_enclosing_type (v)) > > - internal_error (__FILE__, __LINE__, > > - _("Should not be able to create a lazy value with " > > - "an enclosing type")); > > + gdb_assert ((TYPE_LENGTH (value_type (v)) + > value_embedded_offset (v)) > > + <=3D TYPE_LENGTH (value_enclosing_type (v))); > = > This looks like an assertion that should hold for all values, all the tim= e. When > a value has an enclosing type different than its type, the type should be > strictly a subset of the enclosing type. So, it seems a bit odd to check= this > here specifically. It would maybe make more sense to check it when > modifying the type or enclosing_type of a value. In any case, that's sep= arate > from the current patch. If we find out that it is correct to remove the = existing > internal_error call, then I would just simply remove it (replace it with > nothing). I agree here. I will submit a new version of the patch with the extended t= estcase and the removed assertion if we conclude that it's safe to remove. > Simon Thanks Stephan Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928