From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-oln040092070050.outbound.protection.outlook.com [40.92.70.50]) by sourceware.org (Postfix) with ESMTPS id 3767C389852F for ; Sat, 25 Apr 2020 07:29:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3767C389852F 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=LwhQ9zmTqJe4G3IBS+Wq1wlv9DLN5gBxh4k1ct90T1CwNbEDBDo8jSIDdi85ivI9TQpap0BtRNF3i6x4XBjEpf7bJlY1HJQb5QRmntNLBDzZ4u7yRww+Hd7nAcojtLoMo++kE6sA59jJorAljhvr5yXsOWoxA2L2cOQhDiFAUwovdqm9dbgZTZRtzLyCOemU3iLJFhMAon4Qmlo7vuqBD4xu/V++gkjFbnK8nD5i/K4rYW8lraLSg7yqT1my5WxhzBCW9kxZMS1embagCUuawXL0Fyp/2VcksHasQ4U4XnEZ5ljB3oQsyvvy4tFXLQACVAXbzND2ok8YeEczyFz2KA== 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=jVqtToZhWCT4QfGXhrs0wiKP8KkAJzt3kXgtfiESAX4=; b=WTifFNNntWzbyMOC3M4BbDSLzyQdiwiTsBPkkSt3sxXLWL+pwZCuJTdhas6P33k43yJ1LKHaWaWRQQDt0Lngkpne1aRJcNd+m3vEl84ZM/O9tzo7BamnqPbySW/aS4MPsTDZkmssTR7m9KwRtsFtgQNC7GJHhdvast/R/stbuy1Yht6NWTMLEh3BBnsWplcS/K3EIrXppgmnfqWG6pKGJuxcjfKZs6pVAIneca/tUKXjdqPFNIY7AQXIHjUuWzbuQMVZExb4C5NNJLMJcGZUZG30f4YHOktVwDkWj8AChYxdkoHmW9Cixy/q6nxGsCr7NcfNK1cmGpr/26VUUoKgBQ== 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 DB5EUR03FT029.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::40) by DB5EUR03HT161.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19; Sat, 25 Apr 2020 07:29:46 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (2a01:111:e400:7e0a::4f) by DB5EUR03FT029.mail.protection.outlook.com (2a01:111:e400:7e0a::131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sat, 25 Apr 2020 07:29:45 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:C26A9804BB0F49647A09C42024A96960BC35B6466FC929C1C78499F56206D2AF; UpperCasedChecksum:D8704535E903A9B04F012AC0BCDEFE8EB47947B389C32E930FEDE3085BB830D7; SizeAsReceived:8126; Count:50 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::d57:5853:a396:969d]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::d57:5853:a396:969d%7]) with mapi id 15.20.2937.020; Sat, 25 Apr 2020 07:29:45 +0000 Subject: Re: [PATCHv5] Fix range end handling of inlined subroutines To: Tom Tromey , Andrew Burgess Cc: "gdb-patches@sourceware.org" , Alexandre Oliva References: <20200404220718.GA3917@embecosm.com> <87pnbzqll6.fsf@tromey.com> From: Bernd Edlinger Message-ID: Date: Sat, 25 Apr 2020 09:29:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <87pnbzqll6.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR05CA0082.eurprd05.prod.outlook.com (2603:10a6:208:136::22) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <553eeec6-2275-3b4b-d223-2d19ebe07e09@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.102] (92.211.182.71) by AM0PR05CA0082.eurprd05.prod.outlook.com (2603:10a6:208:136::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 07:29:45 +0000 X-Microsoft-Original-Message-ID: <553eeec6-2275-3b4b-d223-2d19ebe07e09@hotmail.de> X-TMN: [ep8etpXZ4KQ93T821/1iDuqclR/Tn/gI] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 50 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: c522ef90-c96e-4326-e9a5-08d7e8ea6da7 X-MS-TrafficTypeDiagnostic: DB5EUR03HT161: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3DYcYo9M51qPoxApe6TJWreAArEIDcrrSLE3ITZB4k3YiamhV8znwghGX3BJlnxzwAs9re34dtSDh0R5chpuS5eEOnkiXojVcZm7NSAVK1wsnXw/drK5wEN7Y7EZ7UDhXmYw/ocO5LiAkcrJEwMikurXGDjuuYTwblNetmqR/DY7kwLopRTEEDn+23L6kmt8CfvBUSLf5fZUdIr9W16gHw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB5170.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: GLIQLq1cx7nTA3MbVQlHGWfpAVlbHli9PBOAgVU0DcB+zARyExHQgRC2ZeV8mMbgDbNffnVwcfuzXxW2USXhHYfpA2fuAxzCUWOlEy1mOWZAeERsK6GMSZlljM6Sdp9P9ezHfRK8/2/gHvKP7hUn9A== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c522ef90-c96e-4326-e9a5-08d7e8ea6da7 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 07:29:45.9304 (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: DB5EUR03HT161 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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, 25 Apr 2020 07:30:01 -0000 On 4/22/20 11:03 PM, Tom Tromey wrote: >>>>>> "Andrew" == Andrew Burgess writes: > >>> +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. */ > > Andrew> I think we're going to need more of a group discussion on this. > Andrew> Simply saying std::vector is too slow doesn't I'm afraid convince me. > Andrew> There seem to be lots of other places in GDB where both performance is > Andrew> critical, and we use ::push_back. > > Andrew> Is your claim that we should move away from std::vector in all these > Andrew> cases? Is this case somehow special? > > C++ documents push_back as having amortized constant complexity. If > that's not the case for the MS compiler, that seems like a pretty > serious bug there... I guess I'd like some documentation of some kind (a > stackoverflow question, or maybe a test program that shows the vector > growing linearly, or something like that). > The problem is, this is in an inner loop where the overall system performance is severely affected by this bug which is not our fault. BUT for the user this is a GDB bug, and guess what the microsoft debugger will load faster. So why do we take that risk? > I didn't understand the relevance or target of the "n*log(n)" comment. > Maybe give more context, I do not understand your question when all the context is removed. > Andrew> I don't think we should be doing this. This is defined quite clearly > Andrew> in the DWARF spec as being an empty range. No code is associated with > Andrew> this range. As such, it really shouldn't have an impact on how we > Andrew> interpret the rest of the DWARF. > > Andrew> Again, I think you're trying too hard to work around GCC's broken > Andrew> DWARF output. > > Do we know how long GCC has been generating this? > And whether anybody is investigating a fix? > Since gcc-7 IIRC. So these versions can no longer be changed, but they will be around for very long. As I said the only possible outcome is disabling this feature for GCC a back-port of anything more complicated will be way too dangerous. Even that is only gcc-10, gcc-9 and gcc-8. So we missed gcc-7, everybody using that will be in trouble. > I dislike adding workarounds for relatively modern versions of > GCC... I'd prefer these things be fixed in GCC if possible. However, if > that's not possible, I'm also flexible about it. > > Tom > Tom, once a bug has been unfixed for so long, the damage can no longer be undone. So I think we should work around the failuer, which is IMHO neither GCC nor GDB's fault, but a flaw in the DWARF-2 spec. I think the best solution would be to fix the spec, and work around the issue until we have a new dwarf-version. Thanks, Bernd.