From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2017.outbound.protection.outlook.com [40.92.90.17]) by sourceware.org (Postfix) with ESMTPS id F00D2385B833 for ; Mon, 23 Mar 2020 21:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F00D2385B833 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=YWLxXLY24cntJOiDor2FN6Aqpv24sHo06vlMNXGjOwj7yKY8E6Pc21LPXBjdOl34pOHuYE/pwAYQOX+l+D7SpQQUxpuu7S1KcFPYtTIO+d0JfE1zb+bVtPc6SFqu34O7XHA89VPxJHKjNhEMQG3nWM8c5VdISvbYGCgxIyTzlaoPcTkDx3DeqpFDY3yhdbYtwL0bdw46ki/umJIMlW1uuI1crfiUIC/m1OxdFsatnzCoijTCXSgbj18GbM+Z4JEnq2EeriIv/yD3fBx5fsIXXvoGvV/Me2gYUQeYho3PnBTV6vMAh4+84OenkA67dVG6bd4WjSCbTw4OzPtI7Mwb5Q== 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=xNQQYGCJGQiQeb71tFMdP1ZI6JDH5EkeGwhtntaU+to=; b=gU9rx8RxvGL8rXam3AooupeIxZ6gq9nAJSJ7t64lUR5lb0/CPP3EoOxcoaCKYsL69QgrEYX+wuonvyRL1UI3NpxNPK9I6SYwYm/b9PFal37b+pnsSCp+Mj2mRKTsWm2f7OBMoLgzwRirz8qQIzd5m8lmEQwH9XHvuiHCqPqDowfIs2gjeZhzwcWXw5+Byabjr37romUiVtLZ57+16kpZgXvnSnGK3ASU60lUK/OSHNNqzuJPJ5zI4ZB2XwECsGMx/CKpLvn63ulIrNwFjQpT0T6dqlbWnnkW0UAZTDq8D2kg0I0Qm5I9RY4Apx5bCDA/9YUza8Vl/Kb5sBr5sp8Tjw== 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 VI1EUR05FT054.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::3c) by VI1EUR05HT246.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::429) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Mon, 23 Mar 2020 21:25:44 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.233.242.54) by VI1EUR05FT054.mail.protection.outlook.com (10.233.242.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Mon, 23 Mar 2020 21:25:44 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:6E27830205B5318D17B569D784F3818A62F080917554F175286D80279C484085; UpperCasedChecksum:214612A74CD03B7F84AA6B2EC80846552E18469861CBC244B8C9303CB5BD52E8; SizeAsReceived:8105; 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; Mon, 23 Mar 2020 21:25:44 +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: Mon, 23 Mar 2020 22:25:42 +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: FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <41698bca-b9ef-60c3-b07a-6c074c4146cc@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20 via Frontend Transport; Mon, 23 Mar 2020 21:25:44 +0000 X-Microsoft-Original-Message-ID: <41698bca-b9ef-60c3-b07a-6c074c4146cc@hotmail.de> X-TMN: [HFIu9kjDSE/5sRFbp2hgJwEWYnaIPDa/] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 688ab431-6512-4fd6-97d4-08d7cf70bee7 X-MS-TrafficTypeDiagnostic: VI1EUR05HT246: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R+Lj0NjL6SFYWy+DSU10rBqBjL9KPJL9+leE2by43Srd1g89l+cehjtjZVLXCZyhtTU1ckG7uektCuCgNiLKcvPXEP6xXaldaCcqBpk9ed+xwqS5jL9R06IBDdwHktJafoRPT39A25kqZxT9+/Ksi5mN3t/l+Eoe3nDpHc797Jk7WhMnQwzuIKHVrRWkmjKh X-MS-Exchange-AntiSpam-MessageData: R1ysHN2qUAXdPVexETk+1CrqADrQ+aA/TRnBiFc3ye3kTe1H05W7NqG6AuKkH6sYGLM7APRnK1Vc+saSq6XSsmwlPdD9SCUxGWKAQRR9hkWSHu/cVH295YyGfAhWB323NYcmL83cx1I23AgGLX5Rkg== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 688ab431-6512-4fd6-97d4-08d7cf70bee7 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2020 21:25:44.5488 (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: VI1EUR05HT246 X-Spam-Status: No, score=-24.2 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: Mon, 23 Mar 2020 21:25:47 -0000 On 3/22/20 4:25 AM, Bernd Edlinger wrote: > 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++; >> Andrew, this is the place where currently the is-stmt entries are deleted. With your is-stmt patch this code is executed in more cases than before. Therefore I would suggest to convert them to !is_stmt lines for now, but maybe in the long run add a new flag that allows them to be used in the file:line case, but make these lines behave differently when stepping, I am only trying to fix the case where you step out of the subroutine. Bernd.