From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KOIwC8/D3GIOeBkAWB0awg (envelope-from ) for ; Sun, 24 Jul 2022 00:00:15 -0400 Received: by simark.ca (Postfix, from userid 112) id 2B4AA1E5EA; Sun, 24 Jul 2022 00:00:15 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=yjgQNlwu; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED,WEIRD_PORT autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 BE8791E21F for ; Sun, 24 Jul 2022 00:00:13 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 281A13857BA4 for ; Sun, 24 Jul 2022 04:00:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 281A13857BA4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658635213; bh=lHRp6n+X66TDklaAioFoYIbO3YjRkuIanRwzmnnvZuY=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=yjgQNlwuHTUru7kp7IjTTp9CTZFIJ7YF0YUUFuFlOA+8X+0R9H3At0iwLfgWsOR2w M4mKLeHQtu69X1pJ3UF2IAoPZ1ERHiWG/YsgHvbnURQ/2yVBYJHs/nkcSfZDE/Asu7 OrtfDQzGpzKHmk52P6+ZeZlWzgZAOzFMcW04EnWg= Received: from barracuda.ebox.ca (barracuda.ebox.ca [96.127.255.19]) by sourceware.org (Postfix) with ESMTPS id 2812F385841F for ; Sun, 24 Jul 2022 03:59:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2812F385841F X-ASG-Debug-ID: 1658635189-0c856e6b03656d50001-fS2M51 Received: from smtp.ebox.ca (smtp.ebox.ca [96.127.255.82]) by barracuda.ebox.ca with ESMTP id cpGa6o4XxalvnH0P (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Jul 2022 23:59:49 -0400 (EDT) X-Barracuda-Envelope-From: simon.marchi@polymtl.ca X-Barracuda-RBL-Trusted-Forwarder: 96.127.255.82 Received: from simark.localdomain (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) by smtp.ebox.ca (Postfix) with ESMTP id CAD3B441B21; Sat, 23 Jul 2022 23:59:49 -0400 (EDT) X-Barracuda-RBL-IP: 192.222.157.6 X-Barracuda-Effective-Source-IP: 192-222-157-6.qc.cable.ebox.net[192.222.157.6] X-Barracuda-Apparent-Source-IP: 192.222.157.6 To: gdb-patches@sourceware.org Subject: [PATCH] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Date: Sat, 23 Jul 2022 23:59:49 -0400 X-ASG-Orig-Subj: [PATCH] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Message-Id: <20220724035949.976274-1-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtp.ebox.ca[96.127.255.82] X-Barracuda-Start-Time: 1658635189 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://96.127.255.19:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ebox.ca X-Barracuda-Scan-Msg-Size: 6208 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_RULE7568M, WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.99592 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 WEIRD_PORT URI: Uses non-standard port number for HTTP 0.50 BSF_RULE7568M Custom Rule 7568M 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Bug 29374 shows this crash: $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out ... /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. The backtrace is: #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 #1 0x000055555d41c0bb in gdb::copy (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 The problem is that the type that gets passed down to dwarf_expr_context::fetch_result is a typedef whose size has never been computed yet (check_typedef has never been called on it). As we get in the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` variable is therefore set to 0, instead of the actual type length. We then call allocate_value on subobj_type, which does call check_typedef, so the length of the typedef gets filled in at that point. We end up passing to the copy function a source array view of length 0 and a target array view of length 4, and the assertion fails. Fix this by calling check_typedef on both type and subobj_type at the beginning of fetch_result. I tried writing a test for this using the DWARF assembler, but I haven't succeeded. It's possible that we need to get into this specific code path (value_of_dwarf_reg_entry and all) to manage to get to dwarf_expr_context::fetch_result with a typedef type that has never been resolved. In all my attempts, the typedef would always be resolved already, so the bug wouldn't show up. We don't have any tests using entry values, I think it would need DWARF machinery that we haven't implemented yet, like unwind information (can't have entry values with a single stack frame). As a fallback, I could always add a gdb.dwarf2 test with a compiler-generated .S file, we have a few of those. I'm not sure if that's acceptable today though, since the DWARF assembler should really be preferred, it makes tests more maintainable and extensible. Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 --- gdb/dwarf2/expr.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/gdb/dwarf2/expr.c b/gdb/dwarf2/expr.c index 998625833366..6dc5132fb801 100644 --- a/gdb/dwarf2/expr.c +++ b/gdb/dwarf2/expr.c @@ -929,6 +929,11 @@ dwarf_expr_context::fetch_result (struct type *type, struct type *subobj_type, if (subobj_type == nullptr) subobj_type = type; + /* Ensure that, if TYPE or SUBOBJ_TYPE are typedefs, their length is filled + in instead of being zero. */ + check_typedef (type); + check_typedef (subobj_type); + if (this->m_pieces.size () > 0) { ULONGEST bit_size = 0; base-commit: 561e83f7c5cdfb2737ba36a04ea008caa6bcaa36 -- 2.37.1