From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nx103.node02.secure-mailgate.com (nx103.node02.secure-mailgate.com [192.162.87.103]) by sourceware.org (Postfix) with ESMTPS id 6FA3E3858D1E for ; Sat, 6 Apr 2024 05:01:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FA3E3858D1E 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 6FA3E3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.162.87.103 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712379696; cv=none; b=mcgHmrMX4dldK9rx0ctuWZUBkUxXYdPIUJB83CspxyLqABG6iZV+LpHhiaca8st+RS70m2QzCNIy6+bO68AvZYkgJaA7gAhWddlgwuhJhzBsp8anjF+NiV8X2bQQSgaMvfohTeeAelVx2VjbKylxrvHovkvpv4MQ4/vFrO6/1QY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712379696; c=relaxed/simple; bh=th6h1ofVX4A5dnEcOZWXyC9YsXcH0Wf5EyfhAWuUsMc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Rbf8p8o0trSpeLGguNsHjdy0islqbQF3i7Y/CUeK0v6DExZ3/ZsyOEdd+anxaCaN9+28qcRk1GW6fxnaBHSeFjBkocoOrM3TZ62zzeTP+9n30xWt8V8ksKlVV4qNBJzQXHrFQcsnRZFmdKjX8AtQKpt79iG27zsIJHerInpX4Qk= 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 1rsyBF-00FuOc-MS; Sat, 06 Apr 2024 07:01:33 +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 2BD3E282FB6; Sat, 6 Apr 2024 07:01:28 +0200 (CEST) X-SecureMailgate-Identity: web24339892p2;web73.alfahosting-server.de Message-ID: Date: Sat, 6 Apr 2024 07:03:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 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: <20240405151012.14763-1-tdevries@suse.de> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <20240405151012.14763-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <171237968880.2898440.4444331740442598163@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.00560111560254) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8fqxqwLM4xYS+s64AyYrKPPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wEJeywUlV7NIpid7rxl4SYciYvU0PcIHnr34KK4GXrC0K4 8v7Yia/sYqdKzRmZg1Y34jfVqGmZYH7JbI0gGzlASJxSwnc3D9OE/6bFGZ/iTkFRTxbfuBKjJ6eA kw4VYNKT63uv1dNfKmytcmrxXytr+qtj6r9GJQPxmFxwVPJqu4wCkFAiM4mwrqomcIhxxcMPLe5V S9tcRrVqLRRuIlZ9/aMJR8Jg0XraN6ru5DtlouMX1fB0BhYOOf+RUeE6zcoRbZ1E08M3k0hofSXt 3h9NCzCvRwvqVEAQMkdN/mM3fJ/aoemCS4KCIKaKBhzQlo3Mne8kEFi9whdly91uPt+NLCnbZCCQ 9A0VWGfEVXE/yUzqvsaIhIMvM6BjpDC8TSyFs5ZZrz9c88D+kBbOzVSeRAwX31WVY5lWjWxuGSRu xQjr60GqoOx9HrVc1uvPTvBVDAQHcttgVcYaAxonKQ+W17niOlhFcyO9tgQb+/TkwEEqJ2YhaHYK PX4HHcW4fmLLdh/NSb/qpYVFz2DoGXALDlDWozoJ8huPXB1631zQnZMWoMak8txHpbK39gB4pahg CVLBpIl/aZyy6fYqalcaj/JciTrXxhUmnmMzaRlxSAc9RvDsJWk2iVzNKhO4mxGcQ2xIQII6zLiS K1DYRU43kJ59fZW/mXUxWFsIstcuEAdT+LecEOC2wM8oSA+doCQJMK7uSDTZMrTxDg/FS+J5B5hQ 6nsDvccjqgmDvD9Wh0iriKYQ+MpjbSe/KYaEyhXPOcKmf0xFTPNwQnM7OYi/0z6bhalFEM/pjPCQ A+BAltlyW2pi0zxRpLXLB0bNRcDs2DoXlEIuxwcNxsQpSWwQnaPKc3yQvxQmzKsAiXiBbKPQYbP7 hL49lUIO/kzOkA0f4ngLmK0LObbZiXBeyQEprv9tWLblHZG0BpGVlm8R1VrGBzbuJkHtWP5z8FHh 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.2 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/5/24 17:10, 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 | 85 +++++++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 75 insertions(+), 10 deletions(-) > > diff --git a/gdb/symtab.c b/gdb/symtab.c > index 86603dfebc3..0c126d99cd4 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -4166,10 +4166,14 @@ 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->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) > @@ -4177,13 +4181,74 @@ find_epilogue_using_linetable (CORE_ADDR func_addr) > return lte.unrelocated_pc () < pc; > }); > > - while (it->unrelocated_pc () >= unrel_start) > - { > - if (it->epilogue_begin) > - return {it->pc (objfile)}; > - it --; > - } > + 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. Even though this is a corner case, which > + may not happen other than in dwarf assembly test-cases, let's > + handle this. > + > + Move to the last entry in the linetable, and check that it's an > + end_sequence terminating the current function. */ > + gdb_assert (it != &linetable->item[0]); > + it--; > + if (!(it->line == 0 > + && unrel_start <= it->unrelocated_pc () > + && it->unrelocated_pc () < unrel_end)) > + return {}; Why is this check necessary here, and not also when this is not the last function in the line-table? And why is this check necessary at all? > + } > + else > + gdb_assert (unrel_end <= it->unrelocated_pc ()); Why do you not check that 'it' points to an end_sequence at exactly unrel_end? It could be anything at an address much higher PC than unrel_end. Bernd.