From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WYQ6Dk4R/WDtJQAAWB0awg (envelope-from ) for ; Sun, 25 Jul 2021 03:22:54 -0400 Received: by simark.ca (Postfix, from userid 112) id 299671EDFB; Sun, 25 Jul 2021 03:22:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,RDNS_DYNAMIC,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 27EAC1E79C for ; Sun, 25 Jul 2021 03:22:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 46A8B385F018 for ; Sun, 25 Jul 2021 07:22:52 +0000 (GMT) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 76E943853828 for ; Sun, 25 Jul 2021 07:22:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76E943853828 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A91F621F87; Sun, 25 Jul 2021 07:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1627197760; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=K/NJ7ZEs9trq3fXN8yYLhvDh6fgEL4rDTvRPDw+n2xo=; b=sFD7oYX+v5WivxBJCkQBUC4b2/xdpX2e0YVRdO4sjYKTzSpL+JVu26Nkzu459HThR96lVv QjW9powYGk/EHCgWYCFkhpGs8E/Wj56EXmpx5iA0KoJE5xED6VqX+e4l6UghSFXYVjUSvV X99dHdTcHiqLYcNv56km3BzdmwRcETU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1627197760; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=K/NJ7ZEs9trq3fXN8yYLhvDh6fgEL4rDTvRPDw+n2xo=; b=qfyaKfuMIjMD56LP8DtWB+uBxQPgbHR40awY3P01wdd+MjTWIdeTNSHpRR/QSMOoWMB2S+ PMVzFvjTTAXOVKAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 86FFD13E1F; Sun, 25 Jul 2021 07:22:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id IZNPH0AR/WBLOAAAMHmgww (envelope-from ); Sun, 25 Jul 2021 07:22:40 +0000 Date: Sun, 25 Jul 2021 09:22:39 +0200 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [PATCH][gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5 Message-ID: <20210725072237.GA31689@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) 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: , Cc: Tom Tromey Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, [ I've confused things by forgetting to add -gdwarf-4 in $subject of commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11". So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is the default for gcc-11. I keep getting confused because of working with a system gcc-11 compiler that was patched to switch the default back to -gdwarf-4. ] When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default -gdwarf-5), I run into: ... (gdb) print pa_ptr.all^M Unhandled dwarf expression opcode 0xff^M (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all ... What happens is that pa_ptr: ... <2><1523>: Abbrev Number: 3 (DW_TAG_variable) <1524> DW_AT_name : pa_ptr <1529> DW_AT_type : <0x14fa> ... has type: ... <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef) <14fb> DW_AT_name : foo__packed_array_ptr <1500> DW_AT_type : <0x1504> <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type) <1505> DW_AT_byte_size : 8 <1505> DW_AT_type : <0x1509> ... which is a pointer to a subrange: ... <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type) <150a> DW_AT_lower_bound : 0 <150b> DW_AT_upper_bound : 0x3fffffffffffffffff <151b> DW_AT_name : foo__packed_array <151f> DW_AT_type : <0x15cc> <1523> DW_AT_artificial : 1 <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type) <15cd> DW_AT_byte_size : 16 <15ce> DW_AT_encoding : 7 (unsigned) <15cf> DW_AT_name : long_long_long_unsigned <15d3> DW_AT_artificial : 1 ... with upper bound of form DW_FORM_data16. In gdb/dwarf/attribute.h we have: ... /* Return non-zero if ATTR's value falls in the 'constant' class, or zero otherwise. When this function returns true, you can apply the constant_value method to it. ... DW_FORM_data16 is not considered as constant_value cannot handle that. */ bool form_is_constant () const; ... so instead we have attribute::form_is_block (DW_FORM_data16) == true. Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR instead of a PROP_CONST and end up trying to evaluate the constant 0x3fffffffffffffffff as if it were a locexpr, which causes the "Unhandled dwarf expression opcode 0xff". In contrast, with -gdwarf-4 we have: ... <164c> DW_AT_upper_bound : 18 byte block: \ 9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \ (DW_OP_implicit_value 16 byte block: \ ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 ) ... Fix the dwarf error by translating the DW_FORM_data16 constant into a PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same result as with -gdwarf-4: ... (gdb) print pa_ptr.all^M That operation is not available on integers of more than 8 bytes.^M (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \ (PRMS: gdb/20991) ... Tested on x86_64-linux, with gcc-11 and target board unix/gdb:debug_flags=-gdwarf-5. I'd like to commit this to master and then backport to gdb-11-branch. Any comments? Thanks, - Tom [gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5 gdb/ChangeLog: 2021-07-25 Tom de Vries * dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16. --- gdb/dwarf2/read.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 029b8bfad04..6f1b453ef45 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -18254,7 +18254,22 @@ attr_to_dynamic_prop (const struct attribute *attr, struct die_info *die, baton->locexpr.per_cu = cu->per_cu; baton->locexpr.per_objfile = per_objfile; - struct dwarf_block *block = attr->as_block (); + struct dwarf_block *block; + if (attr->form == DW_FORM_data16) + { + size_t data_size = 16; + block = XOBNEW (obstack, struct dwarf_block); + block->size = (data_size + + 2 /* Extra bytes for DW_OP and arg. */); + gdb_byte *data = XOBNEWVEC (obstack, gdb_byte, block->size); + data[0] = DW_OP_implicit_value; + data[1] = data_size; + memcpy (&data[2], attr->as_block ()->data, data_size); + block->data = data; + } + else + block = attr->as_block (); + baton->locexpr.size = block->size; baton->locexpr.data = block->data; switch (attr->name)