From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86232 invoked by alias); 28 Dec 2019 11:09:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 86222 invoked by uid 89); 28 Dec 2019 11:09:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=newer X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092065067.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (40.92.65.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 28 Dec 2019 11:09:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kakub27MZgtzfPDvBRr6idE/u2SksjvfoEzKnJ2fwxsacJX2FpmgyUQSyKs/mKZisK1IEkmp3YkJ5f6cuD6QZrilTkVn99xMvVj+jBkMYV/yZUOkH5nMTJBEhZ6B4NyfHBFd/8zSn2R/v/mVQeTF2W+C7HLPHdrtbH55ghVFsx5p+fl4/6rcG/Z+E0sQR9TBDbIof9MA+N57jyJ/MdL5/6HAN+ERmDu2rxpT2ViQnKe24lK5K07NQNIOdfeEIz2q0K6v/crIHYBL0Zq+MBksU3OMrjIJ6pVyNhkandZ6A1qMGbqfuCVSRvjtdlrz+T7CH0o1MKLWXicI8eYXz32t7w== 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=aqLmDESy5pHSZ3SY3fdesY8BIdJQgOB2GdQPKvqMGlY=; b=chvFLJG4Sp0qocANOpDEqyYmHQyjZVQBF124I34hAHGtWq9Qn/4rDPtAlyOcR0bA9hvHDPoz2c2Kw8q29GeJIbTDQXB/XvzMN7UvgHvkvCkB+O4qYew1HS8fZMlykfTzDj8BltNANQmDKZ6+edCVVF4JytuSCWZpbGjrWAdcm54s+AvK4pvMea7KtdFh7zbzDL9ffKKSTun5AdeNDkIgFnHv8E0PfkaeEE8uE07ALvNZ/PDjG1Rb1jq/bZCaofhZOq/zO3XXjBRj6/CWijWjKEVv3jzyYVVnoZjK2u/mhTWTbqNGpC9G69j+p25SOnJutSeyDDhQWEKf/adF0/Fr2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB5EUR01FT015.eop-EUR01.prod.protection.outlook.com (10.152.4.57) by DB5EUR01HT231.eop-EUR01.prod.protection.outlook.com (10.152.4.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Sat, 28 Dec 2019 11:09:22 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.4.51) by DB5EUR01FT015.mail.protection.outlook.com (10.152.5.0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sat, 28 Dec 2019 11:09:22 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769%7]) with mapi id 15.20.2581.007; Sat, 28 Dec 2019 11:09:22 +0000 Received: from [192.168.1.101] (146.60.252.106) by AM4PR0501CA0045.eurprd05.prod.outlook.com (2603:10a6:200:68::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sat, 28 Dec 2019 11:09:21 +0000 From: Bernd Edlinger To: Andrew Burgess CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH 2/3] gdb: Don't reorder line table entries too much when sorting. Date: Sat, 28 Dec 2019 11:09:00 -0000 Message-ID: References: <20191226221705.GL3865@embecosm.com> In-Reply-To: <20191226221705.GL3865@embecosm.com> x-microsoft-original-message-id: <75683056-6dbf-6262-8985-97cefc0a0a93@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <5654CE2FFCCA344D8CD1C31FF73B6E24@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg01055.txt.bz2 On 12/26/19 11:17 PM, Andrew Burgess wrote: > * Bernd Edlinger [2019-12-25 11:19:50 +0000]: >=20 >> Hi, >> >> when I tried this patch, git am says this: >> >> +foreach p $patterns { >> + gdb_test "step" "/\\* $p \\*/" \ >> + "step to '$p'" >> +} >> + >> --=20 >> 2.14.5 >> >> Applying: gdb: Don't reorder line table entries too much when sorting. >> /home/ed/gnu/binutils-gdb/.git/rebase-apply/patch:294: new blank line at= EOF. >> + >> warning: 1 line adds whitespace errors. >=20 > Thanks, I fixed two whitespace errors in this patch. >=20 >> >> >> I just was curious to try this patch series, >> since this has some overlap with a patch I posted here: >> https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html >> >> we both want to add end_sequence here: >>> @@ -21330,7 +21331,8 @@ lnp_state_machine::record_line (bool end_sequen= ce) >>> else if (m_op_index =3D=3D 0 || end_sequence) >>> { >>> fe->included_p =3D 1; >>> - if (m_record_lines_p && (producer_is_codewarrior (m_cu) || m_is_= stmt)) >>> + if (m_record_lines_p >>> + && (producer_is_codewarrior (m_cu) || m_is_stmt || end_sequen= ce)) >>> { >>> if (m_last_subfile !=3D m_cu->get_builder ()->get_current_sub= file () >>> || end_sequence) >> >> I was not sure, if m_is_stmt is ever false when end_sequence is true, >> but considered that to be safer this way too. >> Does that actually happen? >=20 > Honestly, I didn't check. Like you it seemed to make more sense to > leave things as they are unless I have a good reason to change them. >=20 Neither did I, but when I add an assertion there it is obvious that it happens rarely with gcc-4.8 but very often with gcc-10. > Does how I wrote the test for this help you create a test for you > patch at all? If I can help in any way I'd be happy to try. >=20 Wow, that's a really impressive work... I was able to write a test for the step over inline issue, but it is dependent on the gcc version, gcc-8 or newer generate debug info where the problem exists, but test itself passes with all gcc versions as far as I can tell, it does just not prove much for old gcc versions. I posted everyting again here: https://sourceware.org/ml/gdb-patches/2019-12/msg01052.html In case you want to see. Thanks Bernd.