From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn20801.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::801]) by sourceware.org (Postfix) with ESMTPS id 357F4393742C for ; Fri, 13 Mar 2020 11:26:42 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gi8BxG5sp/Mfy/yKVmaMTL4G53q49V2czUyPgAWOa33FCbHof35rJBK3tcmKippo06VbA/jZ0WyYoDmZo4J8aJH9XhtvOzDcUAHOrYRt/dqwNWu1H4hLBSn5sjr4pOdH46u07Cmmm33dhondwstqfVSTjWH/Gbtb0WVoz9mvnS6Wn1ENgEWZWzz+rnojI5n2dpP79Ja0ZSGJxI0YaJCKPzsNg6EGvNxfSvF7IZOC9AvUCA4uX6FEtaR7ZcF9SfN+gyAHMcIpEONpKtylqHi/WsShBIqeb5biYPipRG60EL6JRmip/3QdrBMvfNXCMGGd88wD3yjCYdzdaiuW+iww9A== 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-SenderADCheck; bh=vYYZtE79zfR0rmYxfNc5lqlf34FpLlZ1pVKuSSUrgFI=; b=np8DYMwazDsTZm9CYmpjjnhwXRRbGz8D3aKgFHg6Klo1+lE8wr4vt1fj4xBwcZqgfI5sHFcg4J3oyiSSbMejssXmxzAkbcO1/3RzgRLGI2Hy5IP8yIAA78t31UWVsYYaCU+a7djEecMskHzQMneON2qiqjYpm75fDSsOmZo6g//6K48COpsW0fmXZOQ7FCzUPcKJssydzeGLGy6d0iczpsSOxVwzO7/ts4He5xG88Kn7YD1Q/chHdg8Nbwb36XpcipgxA4rvtNE/j0SVp6JzOt4BrTXUhLvrtgyWPxnf7DRTfXl38kLnR9RfgZ783lpGZpI8EasKYuVOFRlOvvV0pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hotmail.de; dmarc=pass action=none header.from=hotmail.de; dkim=pass header.d=hotmail.de; arc=none Received: from DB8EUR05FT030.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc0f::37) by DB8EUR05HT211.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc0f::243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Fri, 13 Mar 2020 11:26:40 +0000 Received: from VE1PR03MB5181.eurprd03.prod.outlook.com (10.233.238.57) by DB8EUR05FT030.mail.protection.outlook.com (10.233.238.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Fri, 13 Mar 2020 11:26:40 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:0E02B7579E2C2FD70E5381DAA4A4572FF3D8377AC373EEFD2B6680FABA1E8B00; UpperCasedChecksum:45E40A8B04AC6BC7CDF45E912FE63EFFA64C379A006814888EE76E5F1B759019; SizeAsReceived:8036; Count:49 Received: from VE1PR03MB5181.eurprd03.prod.outlook.com ([fe80::9820:a2b6:2afb:1be3]) by VE1PR03MB5181.eurprd03.prod.outlook.com ([fe80::9820:a2b6:2afb:1be3%5]) with mapi id 15.20.2814.018; Fri, 13 Mar 2020 11:26:40 +0000 Subject: Re: [PATCH] Fix an undefined behavior in record_line From: Bernd Edlinger To: "gdb-patches@sourceware.org" , Andrew Burgess References: Message-ID: Date: Fri, 13 Mar 2020 12:26:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR02CA0071.eurprd02.prod.outlook.com (2603:10a6:208:d2::48) To VE1PR03MB5181.eurprd03.prod.outlook.com (2603:10a6:802:a7::13) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by AM0PR02CA0071.eurprd02.prod.outlook.com (2603:10a6:208:d2::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.19 via Frontend Transport; Fri, 13 Mar 2020 11:26:39 +0000 X-Microsoft-Original-Message-ID: X-TMN: [6iI1nv2i1DOTXwDmpJ1JK0DNFVvJIKNs] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 8468ee27-2986-45ed-51df-08d7c7416638 X-MS-TrafficTypeDiagnostic: DB8EUR05HT211: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Juv8cX12rvAgXrePqusSvkExqqtbArDMjQyl1kSu8SuNBpvysy8Hzbo1dtrRecRBDF3iFl369283uxg1bflO+HTLLth7XWj9BrJNkbwtCGX5YOpQvYUA9YINWTiyleQ7INOnPcvX/1JkKEyHWgxHZN+GeypZwCSloSCNN4Z3qJ9r+C3GsF/bYR0+6OedRSTt X-MS-Exchange-AntiSpam-MessageData: Gnqw6ZFevCy7JJj3xp0Bt7NwP3H9ezv9spIPCkQ485X9XSZPngBrAZGnH77HM4etqPieHF9Nj2TlnH9WLLWRwcgNR7zNgaF/Pp80PBQHWuqEf13jcYst3WyNuq1FX8fnuo3VV5rG6qLh//desLIUOA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8468ee27-2986-45ed-51df-08d7c7416638 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2020 11:26:40.7567 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8EUR05HT211 X-Spam-Status: No, score=-24.6 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 13 Mar 2020 11:26:43 -0000 On 3/13/20 12:15 PM, Bernd Edlinger wrote: > Additionally do not completely remove symbols > at the same PC than the end marker, instead > make them non-is-stmt breakpoints. > > Also fix the condition when the line table need to be resized, > that was wasting one element. > > 2020-03-10 Bernd Edlinger > * buildsym.c (record_line): Fix ub and preserve lines at eof. > --- > gdb/buildsym.c | 28 +++++++++++----------------- > 1 file changed, 11 insertions(+), 17 deletions(-) > > diff --git a/gdb/buildsym.c b/gdb/buildsym.c > index 7155db3..e090fdb 100644 > --- a/gdb/buildsym.c > +++ b/gdb/buildsym.c > @@ -695,7 +695,7 @@ struct blockvector * > } > } > > - if (subfile->line_vector->nitems + 1 >= subfile->line_vector_length) > + if (subfile->line_vector->nitems >= subfile->line_vector_length) > { > subfile->line_vector_length *= 2; > subfile->line_vector = (struct linetable *) > @@ -705,27 +705,21 @@ struct blockvector * > * sizeof (struct linetable_entry)))); > } > > - /* Normally, we treat lines as unsorted. But the end of sequence > - marker is special. We sort line markers at the same PC by line > - number, so end of sequence markers (which have line == 0) appear > - first. This is right if the marker ends the previous function, > - and there is no padding before the next function. But it is > - wrong if the previous line was empty and we are now marking a > - switch to a different subfile. We must leave the end of sequence > - marker at the end of this group of lines, not sort the empty line > - to after the marker. The easiest way to accomplish this is to > - delete any empty lines from our table, if they are followed by > - end of sequence markers. All we lose is the ability to set > - breakpoints at some lines which contain no instructions > - anyway. */ > + /* The end of sequence marker is special. We need to reset the > + is_stmt flag on previous lines at the same PC, otherwise these > + lines may cause problems. All we lose is the ability to set > + breakpoints at some lines which contain no instructions anyway. */ > if (line == 0 && subfile->line_vector->nitems > 0) > { > - e = subfile->line_vector->item + subfile->line_vector->nitems - 1; > - while (subfile->line_vector->nitems > 0 && e->pc == pc) > + e = subfile->line_vector->item + subfile->line_vector->nitems; > + do > { > e--; > - subfile->line_vector->nitems--; > + if (e->pc != pc) When I think about it, I would leave any previous-end-of-sequence makers as is_stmt, so change that to if (p->pc != pc or p->line == 0) as line = 0 should imply is_stmt = 1 Bernd. > + break; > + e->is_stmt = 0; > } > + while (e > subfile->line_vector->item); > } > > e = subfile->line_vector->item + subfile->line_vector->nitems++; >