From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34596 invoked by alias); 25 Dec 2019 11:19:55 -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 34588 invoked by uid 89); 25 Dec 2019 11:19:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=sorting, 2.14.5, 2145, whitespace X-HELO: EUR04-DB3-obe.outbound.protection.outlook.com Received: from mail-oln040092074030.outbound.protection.outlook.com (HELO EUR04-DB3-obe.outbound.protection.outlook.com) (40.92.74.30) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Dec 2019 11:19:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ti7csqD4jkKRCU1+mK94AOqVZRlIY7USP02Lg0frI0N1KNOcA4gI9NewqdD+C0x3igJpmm9mcuTDTSkzKkBARjftcM3KukJwTxgroSV+WtpzUaXyv8yIpN4+CljZLHiJ2bN8kINzglSIoU/qp83XzqIglruUCKnD4StlB2sJfKk634YAmdtg1HhLKbqixoEDpV+kwYa4kcDBCHI8Wa3SQtIRybNfAzYOPz4eJQY5ReOwChK9DJ4Jrx870BEKa0neqIpf+nSCsrLyfBtzTzKIwGtorQiqJ3XONzF3RIeLUB/eHlYNtJ3LaJ6Uzj+QD7mUwfrMX3hvSZrLR0U7fn89gQ== 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=6hMoQgvZBwut+rYVkZoSaXy5S2+uEDuaYtLsniuh3oI=; b=ELVBBqIgRA0PtyROugZ/HKxYWY1Ig6dGnq6T2u39JvbFvFR8rOTrRcGFJ3L9HJ659YYdQS570JaKDoMtjQA/mcClhBAOp4aMoJ0qj9z872Aueerxy1K4XLw6mVODz9VR1o1MVqN+VHPf1Z0tDPVcNMtmIga6fVg1fs1Gc+YoU20nxctsZJWZ2F9A67DUqxY0notm4PDpqKGEbZANn8rw2H8e0GGaCmaQgD3XEYTwqaPLasClXhF5zX+lKDooMxrNU+S0MIsDWSKcexIXStXVYFjT5c5pHO0lAUPJgRyK3qtwgHI+tIS/IJf7ZALRn3i+psVAkLZJmIfv4AqtGCJwkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR04FT030.eop-eur04.prod.protection.outlook.com (10.152.26.54) by HE1EUR04HT218.eop-eur04.prod.protection.outlook.com (10.152.26.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Wed, 25 Dec 2019 11:19:50 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.26.60) by HE1EUR04FT030.mail.protection.outlook.com (10.152.27.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Wed, 25 Dec 2019 11:19:50 +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; Wed, 25 Dec 2019 11:19:50 +0000 Received: from [192.168.1.101] (146.60.252.106) by FR2P281CA0012.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Wed, 25 Dec 2019 11:19:49 +0000 From: Bernd Edlinger To: Andrew Burgess , "gdb-patches@sourceware.org" Subject: Re: [PATCH 2/3] gdb: Don't reorder line table entries too much when sorting. Date: Wed, 25 Dec 2019 11:19:00 -0000 Message-ID: x-microsoft-original-message-id: <9675b3e9-e839-2478-cadf-92d62b9a1032@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <45FBFB0227A3C749B62BC3D0AA3E31DF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg01003.txt.bz2 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 EO= F. + warning: 1 line adds whitespace errors. 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_sequence) > 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_st= mt)) > + if (m_record_lines_p > + && (producer_is_codewarrior (m_cu) || m_is_stmt || end_sequence= )) > { > if (m_last_subfile !=3D m_cu->get_builder ()->get_current_subfi= le () > || 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? Bernd.