From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068076.outbound.protection.outlook.com [40.92.68.76]) by sourceware.org (Postfix) with ESMTPS id 45E44385BF9F for ; Sun, 22 Mar 2020 03:25:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 45E44385BF9F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bernd.edlinger@hotmail.de ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n9J1Nh1JCehehUAR5tWA2I1wgK2JAAft1TjLd+tDgi8DcHiMZeReUPKFGLc5bPD11tLF0cKgxzvvRALzbU2JaP8qYhS1OYSXCpoZ45nJs7ooNC9a/sQuj8gRP8uDtL+Rf9HEvQ7jObKLp9f90isSHUoQijGNfAuTVB5xAtWOzyv1WXc8aj+2+c0ikGLNPFez6Yroj/oJ9LWSWS9oWa5zz9wL+oJHPY93HF7r/rFFPLtbk6X343BbGBbQsDo+b1siwIKen7WowVEUvlyZS8U0Fqg0hKTORE6Wvoi1DalI2mqde62BQclP8/x/1GoKLe/byM6J3P7lXZviy4f3voJWDw== 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=v0pOBTGgfh3iVXfO4KKHi5VXdG2HZ5HwTUhKQO2qU6I=; b=gvAtwF44er85yi9Bxqs/Y4YPHrx0oVVd/z5v8Z4yY0HLzeC/hgK+Qwr8g56lhM9duk8HSp5LFunmwcLTVVR1wfuo3iXWwBOLqnmooiTnLF2PpRX7drlvbpSJjMC/IEHCFzMwnAHC4jO6oxhRo+ZaX7E4Fn6tq7B67isLsnT61/i+6ejoRChnFBwIE/C+xx7yrZ0W0hTMFvqIA1EfBsp1BvWL/FrPn3FYxLSDfNmmGQr2dj7xLoCgqvz4eNGEdFcYXjZpjSPMp702DOZiwS4jLwcL4uLh7eo05mGL/HeYRhN/l3Oe8BbUIS2EMHMVNn08Oyh/zyQnTsQNcN3BKpCapg== 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 VE1EUR02FT045.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1e::3b) by VE1EUR02HT212.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1e::421) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Sun, 22 Mar 2020 03:25:10 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.12.51) by VE1EUR02FT045.mail.protection.outlook.com (10.152.12.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Sun, 22 Mar 2020 03:25:10 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:D436DA1C1082FE78840C829D019AA73EE1DF1E541B7C27FE453791FD824F3897; UpperCasedChecksum:481402C935C6DCDE3AE5BB03085D91ACC3C1AA24F01C062B024BE1474E6CA87B; SizeAsReceived:8036; Count:49 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2835.021; Sun, 22 Mar 2020 03:25:10 +0000 Subject: Re: [PATCHv2] Fix an undefined behavior in record_line From: Bernd Edlinger To: "gdb-patches@sourceware.org" , Andrew Burgess References: Message-ID: Date: Sun, 22 Mar 2020 04:25:09 +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: FR2P281CA0035.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::22) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <544268fc-e6eb-f063-a054-d1482a6030a4@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by FR2P281CA0035.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.17 via Frontend Transport; Sun, 22 Mar 2020 03:25:09 +0000 X-Microsoft-Original-Message-ID: <544268fc-e6eb-f063-a054-d1482a6030a4@hotmail.de> X-TMN: [txyXLaC3IXELXA/21IrNa6r66KeezGjm] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: af3c8737-17b6-48c8-f0d2-08d7ce10a053 X-MS-TrafficTypeDiagnostic: VE1EUR02HT212: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: orEr2bgEitb9ZM08MxgtYDZzA+XEK3UqQ5n27HWdDtPZKueowyxzsetHdQNUknlCErapa/9SuNDBT/htQ2GjRt+SFEKF5SyInHSqOy8tuwbaHwuQ0k1McqsoOqOiVDzI7G+Qlp77/Vixjy9JLZRBowzF3fkj6KZhEBhujdI0UlsvgtJhSbbRJ4ZALVK5ocLA X-MS-Exchange-AntiSpam-MessageData: x06EZv1N7M5sQOfNurVVnU/1JUuY2KGt5OEN3yGWLJumVDpYHouh2MhG43Gt9+9z+CSdNAJbKdIF+Df9w1JjhZ0utnehw2j1GtBqaXLUbw/7sba67XBBbHAPT3AOv/oW6EDW2c5DEo3GdM9tXykkZQ== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: af3c8737-17b6-48c8-f0d2-08d7ce10a053 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2020 03:25:10.5436 (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: VE1EUR02HT212 X-Spam-Status: No, score=-23.8 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP 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: Sun, 22 Mar 2020 03:25:14 -0000 On 3/13/20 12:55 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..960a36c 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 || e->line == 0) > + break; > + e->is_stmt = 0; > } > + while (e > subfile->line_vector->item); > } > > e = subfile->line_vector->item + subfile->line_vectoms++; > Hi everyone, I'd say this should be a no-brainer, fixind undefined behavior, and not removing data when not necessary. Is it OK for trunk? Thanks Bernd.