From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2106.outbound.protection.outlook.com [40.92.90.106]) by sourceware.org (Postfix) with ESMTPS id 8F9CC385DC00 for ; Sat, 4 Apr 2020 04:21:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F9CC385DC00 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=UQwuitjRS3HUxfm4BS/PDeDIlDt3OvkZmnytsgXRJIGnWr2b40R+xsZt6vSePXGq5fhrxfHI4NhGRq3bZXebffUKgCrKF2YYJBhZpac95XjQW7z+xucjbCH/8PYsjSGX65zFPEY4F+nlOwe/yvLjyIp59TTqitbAKkIjhLhE2x6xdGNXGZLAyKEYHntdUSdR/1nwdUqeNroNHAgnvpEPKE5YYtICfAxrd8HUlFwGNQMXmUc+vdMRhfiSsRpErMSIfdpgVeuMPWPVe+cV/MqnvlyBoNSMwUdzn01YmFsbyJpqcB0QmX3twADt8roc3uGZk1MW+YHuH5VLMTx5TivJ5g== 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=H4Bqnb60XcdDkJnNAZ6ej85guqCRfzYxxELzbNYcruA=; b=fwKFxzddAw4xMgp6aPXZGTBv/Bgq/4mLQbjNSa0DWS1axYXnLLaPXE1J80keoH3hOHHrwnnOyL4G86J/HuUU7Xqd7wCD7AJ9HH92D+ebBWA5ayw7ltuoonT7MTotmbrDvx05VPHYYxsu96xeAdCCv3qAm1slIrMS97W5Nlc9uVdaskIJwDGFBmRfmrrzyGAKxIz0F9Gp0aB2/5MwjV8jsRqt3ZfI46HDYWwBRXegbdpJUDRAhvqvntv+Ns88M1FvPgVrh70AzUNc9NhipZQLL7Buo6VcBdG1QtxqWx0V+BelqtguX+hb024t3oIOvgyn900LGSwxjGaYjTqAxaGoww== 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 AM6EUR05FT048.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::41) by AM6EUR05HT144.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::450) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17; Sat, 4 Apr 2020 04:21:58 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (2a01:111:e400:fc11::4f) by AM6EUR05FT048.mail.protection.outlook.com (2a01:111:e400:fc11::479) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Sat, 4 Apr 2020 04:21:58 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:BB9E482EB0EA248A057E381B4362E79935166033133874F7B02D6431EE06BEDB; UpperCasedChecksum:B79C1AAB6F6C40EF2519339599FE14817373F7530A08866EC80D01AE3C4814A2; SizeAsReceived:8111; Count:49 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.2878.018; Sat, 4 Apr 2020 04:21:58 +0000 Subject: Re: [PATCH v3 2/2] Fix an undefined behavior in record_line To: Luis Machado , "gdb-patches@sourceware.org" , Andrew Burgess References: From: Bernd Edlinger Message-ID: Date: Sat, 4 Apr 2020 06:21:56 +0200 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: 8bit X-ClientProxiedBy: AM0PR10CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::16) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <52cb791b-862e-be95-6ac1-e69727f96b89@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by AM0PR10CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Sat, 4 Apr 2020 04:21:57 +0000 X-Microsoft-Original-Message-ID: <52cb791b-862e-be95-6ac1-e69727f96b89@hotmail.de> X-TMN: [+OGIfWX9I3XnASZ5t6T7PhQP0DwUvGmH] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: da8eec76-be5b-4033-b2eb-08d7d84fb69d X-MS-TrafficTypeDiagnostic: AM6EUR05HT144: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XfUwVkZkA7smUKlsygsFLUqsi1RfieIhY+hP31q7AT9tP7qDXPccCxmMQxYxGonVdeCGMBnYFZa5vlw0jza2YrkJzr4fKhtJpPlheVlQ7S3WuhBfvjtMoZvUfQByh/Wufxo7i0XuIuhRt+ui6pmklXze3oh3zRH4sIa6FMd/n+Hd101Ibpm7pGDvRSocPxNh X-MS-Exchange-AntiSpam-MessageData: Ews5Sy0Bp06zSHX8IQG6C5lOsQ7ZXzEra8LYrahbvTX9pEIy7QMZYsoTmzMhGTd1qqEloRlQgTBgO0GJ1LdyRFNIn91rXjF+FGVNi8EVoEKfaIJaiDJE4KIEYcuXXcXeOTucKwnCdp5Jix8jxEMyjw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: da8eec76-be5b-4033-b2eb-08d7d84fb69d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2020 04:21:58.3213 (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: AM6EUR05HT144 X-Spam-Status: No, score=-15.0 required=5.0 tests=BAYES_00, BODY_8BITS, FORGED_MUA_MOZILLA, FREEMAIL_FROM, GIT_PATCH_0, 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, 04 Apr 2020 04:22:15 -0000 On 4/4/20 12:53 AM, Luis Machado wrote: > Hi, > > This seems to have caused a few regressions for aarch64-linux. I'm seeing the following: > > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo from main > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into bar from foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of bar to foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo_cold from foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into baz from foo_cold > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of baz to foo_cold > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo_cold to foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo to main > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo from main > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into bar from foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of bar to foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo_cold from foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into baz from foo_cold > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of baz to foo_cold > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo_cold to foo > FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo to main > > git bisect pointed at this commit: > Oh, dear. Andrew, please watch out, your other patch is also about to change something in this area. I tested on x86_64 where everything looked good, (at least for me, but sime test cases are always faling or are unstable ...) It could be that your patch PATCH 2/2] gdb: Preserve is-stmt lines when switch between files I just saw in my inbox is also trying to address the same issue. I was not aware that you were working on the same issue. Thanks Bernd. > --- > > commit 64dc2d4bd24ff7119c913fff91184414f09b8042 > Author: Bernd Edlinger > Date:   Thu Mar 12 11:52:34 2020 +0100 > >     Fix an undefined behavior in record_line > >     Additionally do not completely remove symbols >     at the same PC than the end marker, instead >     make them non-is-stmt breakpoints. > >     2020-04-01  Bernd Edlinger  > >             * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof. > > --- > > What i see in the log is stepping through lines not working as expected. > > > On 3/27/20 12:50 AM, Bernd Edlinger wrote: >> Additionally do not completely remove symbols >> at the same PC than the end marker, instead >> make them non-is-stmt breakpoints. >> >> 2020-03-27  Bernd Edlinger  >>     * buildsym.c (record_line): Fix undefined behavior and preserve >>     lines at eof. >> --- >>   gdb/buildsym.c | 34 ++++++++++++++++++---------------- >>   1 file changed, 18 insertions(+), 16 deletions(-) >> >> diff --git a/gdb/buildsym.c b/gdb/buildsym.c >> index 2d1e441..46c5bb1 100644 >> --- a/gdb/buildsym.c >> +++ b/gdb/buildsym.c >> @@ -705,27 +705,29 @@ struct blockvector * >>                 * sizeof (struct linetable_entry)))); >>       } >>   -  /* Normally, we treat lines as unsorted.  But the end of sequence >> -     marker is special.  We sort line markers at the same PC by line >> -     number, so end of sequence markers (which have line == 0) appear >> -     first.  This is right if the marker ends the previous function, >> -     and there is no padding before the next function.  But it is >> -     wrong if the previous line was empty and we are now marking a >> -     switch to a different subfile.  We must leave the end of sequence >> -     marker at the end of this group of lines, not sort the empty line >> -     to after the marker.  The easiest way to accomplish this is to >> -     delete any empty lines from our table, if they are followed by >> -     end of sequence markers.  All we lose is the ability to set >> -     breakpoints at some lines which contain no instructions >> -     anyway.  */ >> +  /* The end of sequence marker is special.  We need to reset the >> +     is_stmt flag on previous lines at the same PC, otherwise these >> +     lines may cause problems since they might be at the same address >> +     as the following function.  For instance suppose a function calls >> +     abort there is no reason to emit a ret after that point (no joke). >> +     So the label may be at the same address where the following >> +     function begins.  A similar problem appears if a label is at the >> +     same address where an inline function ends we cannot reliably tell >> +     if this is considered part of the inline function or the calling >> +     program or even the next inline function, so stack traces may >> +     give surprising results.  Expect gdb.cp/step-and-next-inline.exp >> +     to fail if these lines are not modified here.  */ >>     if (line == 0 && subfile->line_vector->nitems > 0) >>       { >> -      e = subfile->line_vector->item + subfile->line_vector->nitems - 1; >> -      while (subfile->line_vector->nitems > 0 && e->pc == pc) >> +      e = subfile->line_vector->item + subfile->line_vector->nitems; >> +      do >>       { >>         e--; >> -      subfile->line_vector->nitems--; >> +      if (e->pc != pc || e->line == 0) >> +        break; >> +      e->is_stmt = 0; >>       } >> +      while (e > subfile->line_vector->item); >>       } >>       e = subfile->line_vector->item + subfile->line_vector->nitems++; >>