From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77459 invoked by alias); 15 Dec 2019 18:12:43 -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 77451 invoked by uid 89); 15 Dec 2019 18:12:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy= X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092072068.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.92.72.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Dec 2019 18:12:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pj3dFJOaR0h3UNFdmnoQ3hZfB5/1jdFIA/O+SnecmJwhvFK8XwnmXpnrfkBmqRrRBanrKvVOLBcDpintjMUQ0UvAufdxxKq0wozVg5IkydmP60wnS5jTgII22kqITfUgbMcFXKD7LV87fP9GBmC2DQwSBGL2v6rz65FC2Y8aObXHFTHYUIqAIPbjH4pM3tVSbUCGnvRP2rJFGcYqq9f86DMYy8TzR9olbqyfW1KI605aehqADCyLALIU1VL15boBcXobZiJc8R1IUDmMfrHYxLBRKHrVPKZ9MSk54Ql9yhFcwWLwK6TSgEKnnqxjL8rQU7gsZTjK2HsJgV7kosRPxA== 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=HwvMdz7oV/75n7rAnGdt7EAolB5yJ46gD4uKp3Rqx7E=; b=Cz5T57nRVRIBUWCpkNvWezakiS9XToocOvMDVhzzoQaI75kz22LpJ1m588d8i7LLI17JfSlhwoCBwVP+Iv1ycFvriAmlUh4EJgMEuRVy/vvuqQ6Dlu6/G0QlrcUEIUBrb5ZMTvatWICK8yye8MpzKqEQZQqFp+TQYVaaP5ENwtJ8Ygwxh0bFP6KSDKM2vY0gNI/RHjOnXftNwH74K5qqtxNr60qfkN1k57NxUHFCgEpEL4ptlARH/SwGVC55TybeS98ElndWBLwfx4oJ43RUHYQv16OFDFtUfu5ffei7SSX36Bqs5V7VGBqgP6mq3+ICVAEnuG4lnyLWl1Accx/93Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com (10.152.16.54) by AM5EUR03HT110.eop-EUR03.prod.protection.outlook.com (10.152.17.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Sun, 15 Dec 2019 18:12:38 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.16.55) by AM5EUR03FT008.mail.protection.outlook.com (10.152.16.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18 via Frontend Transport; Sun, 15 Dec 2019 18:12:38 +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.2538.019; Sun, 15 Dec 2019 18:12:38 +0000 From: Bernd Edlinger To: Simon Marchi , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Fix skip.exp test failure observed with gcc-9.2.0 Date: Sun, 15 Dec 2019 18:12:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B37409D133C314D8B62A4E51408EDE2@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg00692.txt.bz2 On 12/15/19 2:05 PM, Simon Marchi wrote: > On 2019-12-15 6:30 a.m., Bernd Edlinger wrote: >> Hi, >> >> this is the split out patch on skip.exp which fixes a pre-existing >> compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from >> trunk of a few weeks ago at least, likely other versions too). >> >> >> Is it OK for trunk? >> >> >> Thanks >> Bernd. >> >> >=20 > Hi Bernd, >=20 > Just wondering, were you able to figure out which change in debug info le= ad > to this behavior change? The behavior with gcc 9.2.0 seems better to be = me, > I think your patch is ok. >=20 Yes indeed. The change started with gcc-8.1.0 when -gcolumn-info was enabl= ed by default. -gcolumn-info was first implemented in gcc-7.1.0 but default-d= isabled, so you can get the altered behavior already with gcc-7 if you manually enab= le -gcolumn-info. So previously there was just one point where line line 30 (of skip.c) start= ed: [0x00000032] Advance Line by 27 to 28 [0x00000034] Copy [0x00000035] Special opcode 63: advance Address by 4 to 0x4004cb and Lin= e by 2 to 30 [0x00000036] Advance PC by constant 17 to 0x4004dc [0x00000037] Special opcode 7: advance Address by 0 to 0x4004dc and Line= by 2 to 32 with column-info we have line 30 three times with different column: [0x00000034] Advance Line by 27 to 28 [0x00000036] Copy [0x00000037] Set column to 9 [0x00000039] Special opcode 63: advance Address by 4 to 0x4004c6 and Lin= e by 2 to 30 [0x0000003a] Set column to 17 [0x0000003c] Special opcode 75: advance Address by 5 to 0x4004cb and Lin= e by 0 to 30 [0x0000003d] Set column to 3 [0x0000003f] Special opcode 75: advance Address by 5 to 0x4004d0 and Lin= e by 0 to 30 [0x00000040] Special opcode 105: advance Address by 7 to 0x4004d7 and Li= ne by 2 to 32 That could probably be filtered in dwarf2read.c to keep the old behavior, b= ut I agree that the new behavior makes still sense, even if we cannot really use the c= olumn info in the line number info. > I would just remove the unrelated whitespace fix before merging. >=20 Okay, I just replicated you advice regarding 8-space tab columns on skip-inline.exp in the other patch. Exactly those 2 lines were copied where the tabs were not used correctly. Thanks Bernd. > Simon >=20