From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nx214.node02.secure-mailgate.com (nx214.node02.secure-mailgate.com [192.162.87.214]) by sourceware.org (Postfix) with ESMTPS id 5B8013858D1E for ; Thu, 11 Apr 2024 13:57:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B8013858D1E Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=hotmail.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B8013858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.162.87.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712843844; cv=none; b=OnUaYAysHkwK2j17h71sFd9lvn+hE1lsfNA4AKqRDiD4hvKh7eB6OWJNOz70QHgTkCyjhsWUA2LXumVAMHOk4df+24tIkYmkVXABBjOZWuqj010lZeqi2/luYHWYIQAFNKL1eFKCx09cvZaPZ05XidCVmDzSm2RjdD+7bhyq70E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712843844; c=relaxed/simple; bh=xhdhQecJhuc9yJOHvQTKsM2yFy/IZL3G2qIN1G918qs=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=kGKYW8o/lGWzIStEkAVRstD0En+v8mLlK/QLgwjPX6QGRogKRsIIsiYovTb2rpTNjW3M2lOU3HkTpFTeS4j4clY61EeEKsMb//slLqULmGwYkRlb6w5bt53LvQj46Wlr1wlbzoU91o+V5PxEYVzn2GT4tGI3+QCQTYCKiFltJFY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from web73.alfahosting-server.de ([5.44.111.53]) by node02.secure-mailgate.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ruuvU-00FeG7-1n; Thu, 11 Apr 2024 15:57:19 +0200 X-SecureMailgate-Identity: web24339892p2;web73.alfahosting-server.de Received: from proxy01.mail.wum.dogado.net (proxy01.mail.wum.dogado.net [5.44.111.201]) (Authenticated sender: web24339892p2) by web73.alfahosting-server.de (Postfix) with ESMTPSA id 7748A2809D9; Thu, 11 Apr 2024 15:57:14 +0200 (CEST) X-SecureMailgate-Identity: web24339892p2;web73.alfahosting-server.de Message-ID: <4dcf8750-50d3-4818-ab09-6f48978add5d@hotmail.de> Date: Thu, 11 Apr 2024 15:59:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] [gdb/symtab] Fix an out of bounds array access in find_epilogue_using_linetable To: Tom de Vries , gdb-patches@sourceware.org References: <20240409092753.10567-1-tdevries@suse.de> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <20240409092753.10567-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <171284383519.1130543.8538347552111124299@web73.alfahosting-server.de> X-PPP-Vhost: edlinger-online.de X-Originating-IP: 5.44.111.53 X-SecureMailgate-Domain: web73.alfahosting-server.de X-SecureMailgate-Username: 5.44.111.53 Authentication-Results: secure-mailgate.com; auth=pass smtp.auth=5.44.111.53@web73.alfahosting-server.de X-SecureMailgate-Outgoing-Class: ham X-SecureMailgate-Outgoing-Evidence: SB/global_tokens (0.00309334513446) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9zuc8ObjC9ATngMXsufft4PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wEJeywUlV7NIpid7rxl4SYciYvU0PcIHnr34KK4GXrC0K4 8v7Yia/sYqdKzRmZg1Y34jfVqGmZYH7JbI0gGzlA506Tx2NwRPP5Shu7tTlDvkFRTxbfuBKjJ6eA kw4VYNKT63uv1dNfKmytcmrxXytr+qtj6r9GJQPxmFxwVPJqu4wCkFAiM4mwrqomcIhxxcMPLe5V S9tcRrVqLRRuIlZ9h+xYYdgMjoBvNAEokBHg4uMX1fB0BhYOOf+RUeE6zcoRbZ1E08M3k0hofSXt 3h9NCzCvRwvqVEAQMkdN/mM3fJ/aoemCS4KCIKaKBhzQlo3Mne8kEFi9whdly91uPt+NLCnbZCCQ 9A0VWGfEVXE/yUzqvsaIhIMvM6BjpDC8TSyFs5ZZrz9c88D+kBbOzVSeRAwX31WVY5lWjWxuGSRu xQjr60GqoOx9HrVc1uvPTvBVDAQHcttgVcYaAxonKQ+W17niOlhFcyO9tgQb+/TkwEEqJ2YhaHYK PX4HHcW4fmLLdh/NSb/qpYVFz2DoGXALDlDWozoJ8huPXB1631zQnZMWoMak8txHpbK39gB4pahg CVLBpIl/aZyy6fYqalcaj/JciTrXxhUmnmMzaRlxSAc9RvDsJWk2iVzNKhO4mxGcQ2xIQII6zLiS K1DYRU43kJ59fZW/mXUxWFsIstcuEAdT+LecEOC2wM8oSA+doCT7FnYFfjimMpnwh+T6Ny4uB5hQ 6nsDvccjqgmDvD9Wh0iriKYQ+MpjbSe/KYaEyhXPOcKmf0xFTPNwQnM7OYi/0z6bhalFEM/pjPCQ A+BAltlyW2pi0zxRpLXLB0bNRcDs2DoXlEIuxwcNxsQpSWwQnaPKc3yQvxQmzKsAiXiBbK4JEdCM SjDcvCKM6oKo/Q4f4ngLmK0LObbZiXBeyQEprv9tWLblHZG0BpGVlm8R1VrGBzbuJkHtWP5z8FHh 4U0LdJdGOkWcwc2n5r+Cy9HGHN0ZH9R9y+BoEHkLvpvHd9/c3z1ig5BRHUda70b6rNnhHybVHWnu kQ5J3NZf3Sto4BAah0N3qPEwUyYM+XoU0gPKPpjFSmnirfv07lDyNv3wWEAHjVTdTWulrxgvlgAb v+NivHPR1cUy3QhHKE+wc2XRvbUG4LgSKHOiDLZ/t1A= X-Report-Abuse-To: spam@node04.secure-mailgate.com X-Spam-Status: No, score=-20.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_SOFTFAIL,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 List-Id: On 4/9/24 11:27, Tom de Vries wrote: > From: Bernd Edlinger > > An out of bounds array access in find_epilogue_using_linetable causes random > test failures like these: > > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $fn_fba > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: check frame-id matches > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: bt 2 > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: up > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $sp_value == $::main_sp > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $::main_fba > FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: [string equal $fid $::main_fid] > > Here the read happens below the first element of the line > table, and the test failure depends on the value that is > read from there. > > It also happens that std::lower_bound returns a pointer exactly at the upper > bound of the line table, also here the read value is undefined, that happens > in this test: > > FAIL: gdb.dwarf2/dw2-epilogue-begin.exp: confirm watchpoint doesn't trigger > > Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table") > > Co-Authored-By: Tom de Vries > > PR symtab/31268 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268 > --- > gdb/symtab.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 84 insertions(+), 10 deletions(-) > > diff --git a/gdb/symtab.c b/gdb/symtab.c > index 86603dfebc3..e032178aaa6 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -4156,6 +4156,9 @@ find_epilogue_using_linetable (CORE_ADDR func_addr) > if (!find_pc_partial_function (func_addr, nullptr, &start_pc, &end_pc)) > return {}; > > + /* While the standard allows for multiple points marked with epilogue_begin > + in the same function, for performance reasons, this function will only > + find the last address that sets this flag for a given block. */ > const struct symtab_and_line sal = find_pc_line (start_pc, 0); > if (sal.symtab != nullptr && sal.symtab->language () != language_asm) > { > @@ -4166,24 +4169,95 @@ find_epilogue_using_linetable (CORE_ADDR func_addr) > = unrelocated_addr (end_pc - objfile->text_section_offset ()); > > const linetable *linetable = sal.symtab->linetable (); > - /* This should find the last linetable entry of the current function. > - It is probably where the epilogue begins, but since the DWARF 5 > - spec doesn't guarantee it, we iterate backwards through the function > - until we either find it or are sure that it doesn't exist. */ > + if (linetable == nullptr || linetable->nitems == 0) > + { > + /* Empty line table. */ > + return {}; > + } > + > + /* Find the first linetable entry after the current function. Note that > + this also may be an end_sequence entry. */ > auto it = std::lower_bound > (linetable->item, linetable->item + linetable->nitems, unrel_end, > [] (const linetable_entry <e, unrelocated_addr pc) > { > return lte.unrelocated_pc () < pc; > }); > + if (it == linetable->item + linetable->nitems) > + { > + /* We couldn't find either: > + - a linetable entry starting the function after the current > + function, or > + - an end_sequence entry that terminates the current function > + at unrel_end. > + > + This can happen when the linetable doesn't describe the full > + extent of the function. This can be triggered with: > + - compiler-generated debug info, in the cornercase that the pc > + with which we call find_pc_line resides in a different file > + than unrel_end, or > + - invalid dwarf assembly debug info. > + In the former case, there's no point in iterating further, simply > + return "not found". In the latter case, there's no current > + incentive to attempt to support this, so handle this > + conservatively and do the same. */ > + return {}; > + } > > - while (it->unrelocated_pc () >= unrel_start) > - { > - if (it->epilogue_begin) > - return {it->pc (objfile)}; > - it --; > - } > + if (unrel_end < it->unrelocated_pc ()) > + { > + /* We found a line entry that starts past the end of the > + function. This can happen if the previous entry straddles > + two functions, which shouldn't happen with compiler-generated > + debug info. Handle the corner case conservatively. */ > + return {}; > + } > + gdb_assert (unrel_end == it->unrelocated_pc ()); > + > + /* Move to the last linetable entry of the current function. */ > + if (it == &linetable->item[0]) > + { > + /* Doing it-- would introduce undefined behaviour, avoid it by > + explicitly handling this case. */ > + return {}; > + } > + it--; > + if (it->unrelocated_pc () < unrel_start) > + { > + /* Not in the current function. */ > + return {}; > + } > + gdb_assert (it->unrelocated_pc () < unrel_end); > + > + /* We're at the the last linetable entry of the current function. This > + is probably where the epilogue begins, but since the DWARF 5 spec > + doesn't guarantee it, we iterate backwards through the current > + function until we either find the epilogue beginning, or are sure > + that it doesn't exist. */ > + for (; it >= &linetable->item[0]; it--) > + { > + if (it->unrelocated_pc () < unrel_start) > + { > + /* No longer in the current function. */ > + break; > + } > + > + if (it->epilogue_begin) > + { > + /* Found the beginning of the epilogue. */ > + return {it->pc (objfile)}; > + } > + > + if (it == &linetable->item[0]) > + { > + /* No more entries in the current function. > + Doing it-- would introduce undefined behaviour, avoid it by > + explicitly handling this case. */ > + break; > + } > + } > } > + > return {}; > } > > > base-commit: 9132c8152b899a1683bc886f8ba76bedadb48aa1 The patch is OK from my side. Thanks Bernd.