From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by sourceware.org (Postfix) with ESMTPS id 937CF385B834 for ; Tue, 24 Mar 2020 21:24:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 937CF385B834 Received: by mail-qk1-x744.google.com with SMTP id i6so225633qke.1 for ; Tue, 24 Mar 2020 14:24:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2jU5OV0deK4Mv7PAVE2Ugsh0eX4q5YF4pgR4m8yrecI=; b=ikYeoKC+yclRDYmeOHk36DBWFhXykMdgxfuaQLYcMtX+257khvndnT3ONhUQvyVWgP Q+hRFl+GPS4/MgH3+ZZBSGC10nplhsTPlf9U8yroqyB13hr/ktgW7jx1W2F9JBNlZb7O kuQc5NRtevQp7ebJjzdaV824sUS31zV9oRyqMRupIhLfHWryNN0ZUqHeNhcFlv+Z8dGf NzUcWTADOgdY/oGZUJn0FOVLhd4n4OxHOWXmQVgzua+fvcf6a3mD/F/m/xFGaCI+uL2s Uut/Q7+19qMsINbZtxgfGGMhynrcoKi2QiEVXjIu0bTMZUvK8JnKFnrdvf0Nr19p1oS/ VUbQ== X-Gm-Message-State: ANhLgQ0CfeiNc2rg1Fmsgp6zghTwIGk52F8bjPHP4eH1PTxlKwe3m8eu gZYlGu00cOmDLfFj4EE4QMpCWJSRslg= X-Google-Smtp-Source: ADFU+vtSORY3lYcvpbqGfh3BfhgxAMgZI2jQqayYFWSg1w6RJdoY4v9NSZNtaaDsVYemOhVc5mobDQ== X-Received: by 2002:a37:6d3:: with SMTP id 202mr27770640qkg.267.1585085047779; Tue, 24 Mar 2020 14:24:07 -0700 (PDT) Received: from [192.168.0.185] ([191.249.236.47]) by smtp.gmail.com with ESMTPSA id z23sm14274934qkg.21.2020.03.24.14.24.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2020 14:24:07 -0700 (PDT) Subject: Re: [PATCH] Find tailcall frames before inline frames From: Luis Machado To: Tom Tromey Cc: Tom Tromey , gdb-patches@sourceware.org References: <20200220155820.22809-1-tromey@adacore.com> <87sgip6rk9.fsf@tromey.com> <665eda59-ae52-42f4-b3b2-e3a070036ca8@linaro.org> <8736adi7f5.fsf@tromey.com> <9b864a68-3c28-9c25-6e3d-252777143e52@linaro.org> Message-ID: Date: Tue, 24 Mar 2020 18:24:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <9b864a68-3c28-9c25-6e3d-252777143e52@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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: Tue, 24 Mar 2020 21:24:10 -0000 Hi Tom, On 3/13/20 10:31 AM, Luis Machado wrote: > On 3/12/20 6:34 PM, Tom Tromey wrote: >>>>>>> "Luis" == Luis Machado writes: >> >> Luis> This has caused quite a few failures in the following tests for >> Luis> aarch64-linux: >> >> I still haven't really tried to reproduce this yet. >> I'll try tomorrow, I hope. >> >> Luis> ../../../repos/binutils-gdb/gdb/frame.c:579: internal-error: >> frame_id >> Luis> get_frame_id(frame_info*): Assertion `fi->level == 0' failed. >> >> Meanwhile I wonder if this is the same as >> >> https://sourceware.org/pipermail/gdb-patches/2020-February/165511.html >> >> Tom >> > > The mention of fi->level looks the same, but i haven't looked into it yet. > > I was planning to pinpoint the failure point in order to make this > easier to solve. Having spent a few days trying to understand this problem, it seems all of these fi->level assertions (including https://sourceware.org/bugzilla/show_bug.cgi?id=22748) are related to attempting to unwind from places not safe to do so. That is, we're trying to unwind some content (registers for example) before a given frame is assigned a frame id. For some cases we can see compute_frame_id being invoked in recursion for the same frame, which would lead to an infinite recursion. So the assertion catches this. In my particular case, the call to dwarf2_tailcall_sniffer_first inside dwarf2_frame_cache leads to such infinite recursion, since no frame id has been assigned to the frame being used yet. It will be assigned by the time compute_frame_id is done. I think dwarf2_tailcall_sniffer_first would have to be called from somewhere else, or conditions put in place. But I'm afraid adding more conditions would complicate things further. And this code is already reasonably complicated. Since this is causing a number of inlining test failures for aarch64 and, from what i saw, some other architectures like s390, should we consider reverting this while we discuss/review a reworked version of the patch?