From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-oln040092070051.outbound.protection.outlook.com [40.92.70.51]) by sourceware.org (Postfix) with ESMTPS id 7B1F7385E830 for ; Sat, 21 Mar 2020 20:31:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7B1F7385E830 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=TyZNHvJ07pTX9LzgLYxi4h8qPEUSgQeVathmL1ywL0cB4JPITETrMdpBZZKG/m8crNAR5VxEMCalWR+51lBuTqfRZclkUBxpXuA96Sm7a/dVY/PWdpJE5A5okLDaKgm2QtHMfUeyX/vqXAxTXzbME7mkDKrdFcyRu3Ovrot7PL1VXMnIoYeDhoZ9ea3nvPMZbK2E+cUReXGyWhdpxtTbL1DjJP+nsjwCQtc8aMomolrydxvXIDtN0t6Pyi96f+2uB+HhYjeuf87/MQ8JFBYuBgus5W9wn6PRsN+s3PhFg7xAKur+dbG9dSD+bgIRDiUa8j/M6aNlEaDO1u+stEKNnQ== 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=a02B1by2cRf/R6BhZO1Pmh9rS7gQKoFXzKfKt/6fhTY=; b=l4J9QD2oUf/quqXRhGhdfe3SK+dFdORS5maHWoit8en3f5TgnCJNpQNJGWonpoF5LCVCsbgDEcsk7aytUxRoWH5aK0r/581W0MRpMPdQT5mIqFPwWMtqm07upYuMqQRdrptYSNxHqfxIzvaVbuzcFY9WNyq4ZX86yHp14GGlrm3fsEkCMrh3NRUgdMiGOCyKgpEl0M6ZhPPwjUgayYkIJJGV2g412QH0d/llqDn7bAbzSILo1VGzNHVDPPeU/sYpPynYwQkcTs9cYtSIEHWEoa0LwPq1EW4FXn2Pm3B+Mm/YXXHduMuQS7E+f5LH1pPIOCVdoQE20kUJyfsHm+xC4w== 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 VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e09::3a) by VE1EUR03HT232.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e09::449) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Sat, 21 Mar 2020 20:31:10 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.18.58) by VE1EUR03FT041.mail.protection.outlook.com (10.152.19.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Sat, 21 Mar 2020 20:31:10 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:B6DC1E3DEFB78911ACB82C05D3E814EB74CCDBBB2A9DF34513F603497CE51438; UpperCasedChecksum:F0A0A8D746C72E7F926C981BB3901AC6E8D87C06F5CB10890119916D92DD0461; SizeAsReceived:8801; Count:50 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; Sat, 21 Mar 2020 20:31:09 +0000 Subject: Re: [PATCHv3] Fix range end handling of inlined subroutines From: Bernd Edlinger To: Andrew Burgess Cc: Christian Biesinger , "gdb-patches@sourceware.org" References: <94e33268f64060fc887670f4ee5ed524050cbcc7.1580902412.git.andrew.burgess@embecosm.com> <20200311220231.GJ3317@embecosm.com> <20200317222757.GN3317@embecosm.com> Message-ID: Date: Sat, 21 Mar 2020 21:31:07 +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: ZR0P278CA0015.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::25) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <565dcd60-722c-951d-778f-6b9c7e55615c@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by ZR0P278CA0015.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.15 via Frontend Transport; Sat, 21 Mar 2020 20:31:09 +0000 X-Microsoft-Original-Message-ID: <565dcd60-722c-951d-778f-6b9c7e55615c@hotmail.de> X-TMN: [cKvFYG7I05LSsFkanaFPTJC+XvDQBmpw] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 50 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 6623ddda-55ec-46e9-8190-08d7cdd6ca1f X-MS-TrafficTypeDiagnostic: VE1EUR03HT232: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5Rf2yvfRKpSsy2Ppj3nHXJlA0B8f1gPVWi8hQHhZjYTuZ9xzYaKdxrNUpf7sJk4gW29pHubn5+3F8YhtCAc7W9bV/KoEyvq2JZLJbxC+OKUi84pdxY1HTObMynTuy76A6COmujwTfEAGL9wCfeoRjgVeiUQrCgumdN1mUOfrbvz3Wd4vmP15pRrdEMLStNnS X-MS-Exchange-AntiSpam-MessageData: Ix6Tec3lvSqpuoMnvugOlQ+gEv+o0EOjM/vYALT2+FEsGECKUIpxyFUSY4ZNCk8+LKfUmh2ceQ9dnuSUt7vTvEoEaDuIa8xo4Jj/aRFCGPyYZk+CkWb5bRFyL53yNTkt6D4E3wjKEGb5aI5JNgPXAw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6623ddda-55ec-46e9-8190-08d7cdd6ca1f X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2020 20:31:09.9229 (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: VE1EUR03HT232 X-Spam-Status: No, score=-17.4 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, 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: Sat, 21 Mar 2020 20:31:13 -0000 On 3/19/20 2:33 AM, Bernd Edlinger wrote: > On 3/17/20 11:27 PM, Andrew Burgess wrote: >> >> Are you arguing that we shouldn't use std::vector anywhere in GDB? Or >> that this particular piece of code shouldn't use std::vector? >> > > No, in general std::vector is just fine. > I think just here it is especially important to be below O(n*log(n)), > and don't depend on the underlying implementation. > >> It was my understanding that we were moving GDB away from bespoke >> container management code unless there was a very compelling reason. >> I think as a minimum any new code that was written not using std:: >> data structures (or some other gdb specific type) would need a comment >> explaining why, if nothing else to stop someone replacing the code >> with std:: types a few months down the line. >> > > Right, good point. > I can add a comment here, so that will not happen: > > index 46f985a..4f0d536 100644 > --- a/gdb/buildsym.c > +++ b/gdb/buildsym.c > @@ -736,6 +736,10 @@ struct blockvector * > void > buildsym_compunit::record_inline_range_end (CORE_ADDR end) > { > + /* The performance of this function is very important, > + it shall be O(n*log(n)) therefore we do not use std::vector > + here since some compilers, e.g. visual studio, do not > + guarantee that for vector::push_back. */ > if (m_inline_end_vector == nullptr) > { > m_inline_end_vector_length = INITIAL_LINE_VECTOR_LENGTH; > > > Does that look good (also from the english)? > Hi Andrew, how are you doing? are you ok? Bernd.