From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074010.outbound.protection.outlook.com [40.92.74.10]) by sourceware.org (Postfix) with ESMTPS id D1B2A385DC00 for ; Sat, 4 Apr 2020 16:06:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D1B2A385DC00 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=KAfdEwV6rnUvU/ESbTGj/ZrOTv1y+yokTobrorB1kRtSHUK7KzB1kdsN2bj+b4L/VwnVQK2hrvejmA93Aq+Kw6iClH4OEDiAKd7G+7RtIGvp4diYYN84UWO8MZRE7Dqn8kZ8ilO8mYmY6/OuGU0nUKv9R9O9NDn6dg6N9zWPuQdky61cMHFTfRO01pvckHzoqj5R9dis22+8JlzLjridbNTTkd0GBJTcgjRKYHDPEdckdm7GlqPnrU/upEoZN3WMjwhH0YUsq1pBBi9ov4xBmnLAZEt3mdZuVTusmlP95pqTuD9v1H1JlaJ7rrnpnj7HheeJ10fcWVofGKvz/FrUqw== 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=6O2QAlvMl8vl7Bg8z1Scj1jzrUL3BGDgBeVPqvaxtCI=; b=Qf+Ro2t2S6g+3WyXPBcCu6XjSDnG04t25tLdnh39XC03FUmV+HDS/teulgIfR/qjJtaAiu5C5JSq1O0TMyn/QIg+g2OagYC6kLpdi4TZUCSIoUra6d6kFYpXpnRaOqJrTreURWzO7J5t0nC6rFV7EJEaMrOMsjMIGCKSMfaIUQZgYZKjVUlz90bWRWit7Y9hW5ABxVitVN+OMQs+d0vcKeQgbUCcgs5WNZvtbEHkVndQBKb0WXDryQVRKYW2Bflq24U6St5VeACuvDfpOc5o6AGQGKAHmc4JJ8Ktiur/BAi1IFHLKVTJnZO5QHTGdbJZCewDQkwPa7xkL/76rWM8Bw== 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 HE1EUR04FT051.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::45) by HE1EUR04HT028.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::310) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Sat, 4 Apr 2020 16:06:42 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (2a01:111:e400:7e0d::45) by HE1EUR04FT051.mail.protection.outlook.com (2a01:111:e400:7e0d::296) 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 16:06:42 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:362F8AE790DC76B64EABA8031FDB6FE6490CE347CCBF6737E167EF9E8C85197F; UpperCasedChecksum:5732F3B2802E3CA61562B367AC2E8C5EB15E6F3AC1B277A0D5A4AA839687B475; SizeAsReceived:8336; 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 16:06:42 +0000 Subject: Re: [PATCH v3 2/2] Fix an undefined behavior in record_line To: Luis Machado , "gdb-patches@sourceware.org" , Andrew Burgess References: <3a407c0c-e63b-4c3f-dec2-57ff7470164b@linaro.org> From: Bernd Edlinger Message-ID: Date: Sat, 4 Apr 2020 18:06:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <3a407c0c-e63b-4c3f-dec2-57ff7470164b@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM3PR05CA0100.eurprd05.prod.outlook.com (2603:10a6:207:1::26) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <0d49ca2e-ad68-3e8a-c838-b901610c5f5a@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by AM3PR05CA0100.eurprd05.prod.outlook.com (2603:10a6:207:1::26) 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 16:06:41 +0000 X-Microsoft-Original-Message-ID: <0d49ca2e-ad68-3e8a-c838-b901610c5f5a@hotmail.de> X-TMN: [DCFEyCR+cMkg8DCy9yXKvE2KiiNYyJy9] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: e29f2770-f3ed-49c9-3f1d-08d7d8b22a4a X-MS-TrafficTypeDiagnostic: HE1EUR04HT028: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fIQB/s4q5u/fVJA64kfi7daMBAdfraFlVNnJ7Y+4WhnwTTczcJdp+gn7+TPvirPcDd9+gRhPYzkLNAYq/no4m92JDCYXTlLR9Vod6088ygcmNDT/3ooe1PXGd+k8J3cGCIcLrchZGnf3/iOFg4uFYBcLjwPHPpqW1dqb2PsUx32KkeVZwr2w0VdsiyauK+Qo 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: o2AYUbUdadCzzZApcsk6pMmbAQS62kj9YKhpcP3dLRgZNVcKUeb8Se2tp2Mymcnwq28zU1eJ5ZmmL7IRJhANcpzLdIlw+JbIRkyc75gI9kSEd4k9XHXvJy7KDilirZaCZ3vHKS39KQmqZ8BmIW0o4Q== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e29f2770-f3ed-49c9-3f1d-08d7d8b22a4a X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2020 16:06:42.7598 (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: HE1EUR04HT028 X-Spam-Status: No, score=-15.3 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, RCVD_IN_MSPIKE_H2, 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 16:06:47 -0000 Hi Luis, the attachments seem to be twice the lo-cold.c linetables, I wonder if the hi-cold.c linetable are missing, to somehow make the picture complete? Thanks Bernd. On 4/4/20 3:56 PM, Luis Machado wrote: > Hi Bernd, > > On 4/4/20 4:06 AM, Bernd Edlinger wrote: >> On 4/4/20 6:21 AM, Bernd Edlinger wrote: >>> >>> >>> 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: >>>> >> >> Louis, >> >> So, I cannot do much, to debug aarch64 here. >> I would however like to know what the output of the test result is, >> when it fails, that is where the step does stop when it is not where it should. > > On a quick look, we're stopping at the wrong location during an attempt to break at "main". I think things just derail from there. > > For now, please find attached a couple logs, one without regressions and one with the failing tests. > > Also, I've attached the decoded/raw line information for both binaries from this testcase. I can play with it further to get more information if you need. Hopefully this data is useful for now. > > Let me know otherwise. > >> >> And how the line table looks in the test case when it is compiled on aarch64, >> btw. which gcc version do you use? > > The compiler version is gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1). > >> >> Thanks >> Bernd. >> >>> >>> 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++; >>>>>