From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2DBF23858D28 for ; Tue, 1 Nov 2022 10:20:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2DBF23858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667298042; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BHIjkarlDehycKImjbXPM8HwZepJKHnq3f2F8iZEX7Y=; b=asUz63wQ+IVAsSx3tGASsgU3gbBHmMm0zHbc2X/YXWIExMRJdCVJSzoQe8ZiHaQ73fulMk Vm21q/x4PU8U/1p4Y73vRMR5+LkfoDIPqYxqz+yq0Y2zQIPYqpwJXbEZI0Q1dOZtcyDRLo nIr3sPUFNXje46JNG9uOJC9W61sHxNY= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-116-Wj7abUbZN3aSRosKhPXHRQ-1; Tue, 01 Nov 2022 06:20:39 -0400 X-MC-Unique: Wj7abUbZN3aSRosKhPXHRQ-1 Received: by mail-qk1-f198.google.com with SMTP id bp10-20020a05620a458a00b006fa29f253dcso4807932qkb.11 for ; Tue, 01 Nov 2022 03:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BHIjkarlDehycKImjbXPM8HwZepJKHnq3f2F8iZEX7Y=; b=no7yd8ygVq4sAU0krLOVReBk6wSCsz7TvRJoNgpJToMlqH5DmRkqd0WMscjE15N8Wf g+WySvr6ULr89xHTJHkAYvIswUF4yqbUQ6op2E3lGKUm861WdAw2wtC05oINOOG8bAmB 0T7ssDSCLeAd/Hr4OF8wKnVsk0pMuprWhyFkfOAtdXlIO62gjF4DkEfktBw2j1iUiPVQ Kg0fZzm2GuqkSUXyJgyYo2DhH3O3qJsvl6H0frKBTrD5dHAjsFF5hx0aWeDvYa21yMUR v5FpzSQOPICaIalhVBcxdoju7dyL1fQGsvhxv0mcLRnhstD8BKtGbNgboTwHKwrW6hHR mQDQ== X-Gm-Message-State: ACrzQf36o04PDmSwItxIkeztrhol8dD0V22vk9oFJClX9ic4SVH3LxB8 LIXGgN0LFOc1K92PIrklO1bZqa4HcppmlFxOohFzf7C5Xi/GSQrZ7MV/949RYq+rAN36L7F37zf R2SDCtzzm3ABuQK8OE3+wig== X-Received: by 2002:a05:6214:19e3:b0:4b6:8a99:3054 with SMTP id q3-20020a05621419e300b004b68a993054mr14799077qvc.108.1667298038479; Tue, 01 Nov 2022 03:20:38 -0700 (PDT) X-Google-Smtp-Source: AMsMyM48qu/8bxHrd+jQPNdNGUNqhRdxAk6Kww1BLw5867sS9bCH20oZOhG10b0vQm83Q94VQvOIdg== X-Received: by 2002:a05:6214:19e3:b0:4b6:8a99:3054 with SMTP id q3-20020a05621419e300b004b68a993054mr14799055qvc.108.1667298038183; Tue, 01 Nov 2022 03:20:38 -0700 (PDT) Received: from [192.168.0.45] (ip-62-245-66-121.bb.vodafone.cz. [62.245.66.121]) by smtp.gmail.com with ESMTPSA id bn7-20020a05622a1dc700b003a50248b89esm4859457qtb.26.2022.11.01.03.20.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 03:20:37 -0700 (PDT) Message-ID: <711495ea-57f4-276d-db50-067b29c14de6@redhat.com> Date: Tue, 1 Nov 2022 11:20:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Question: [PATCH] Change calculation of frame_id by amd64 epilogue unwinder To: Carl Love Cc: "gdb-patches@sourceware.org" , Ulrich Weigand , Will Schmidt References: From: Bruno Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 31/10/2022 21:16, Carl Love wrote: > Bruno: > > Sorry for the slow response, I was out all of last week. > > It looks like you committed the patch: > > commit 49d7cd733a7f1b87aa1d40318b3d7c2b65aca5ac > Author: Bruno Larsen > Date: Fri Aug 19 15:11:28 2022 +0200 > > Change calculation of frame_id by amd64 epilogue unwinder > > When GDB is stopped at a ret instruction and no debug information is > available for unwinding, GDB defaults to the amd64 epilogue unwinder, to > be able to generate a decent backtrace. However, when calculating the > frame id, the epilogue unwinder generates information as if the return > instruction was the whole frame. > > This was an issue especially when attempting to reverse debug, as GDB > would place a step_resume_breakpoint from the epilogue of a function if > we were to attempt to skip that function, and this breakpoint should > ideally have the current function's frame_id to avoid other problems > such as PR record/16678. > > This commit changes the frame_id calculation for the amd64 epilogue, > so that it is always the same as the dwarf2 unwinder's frame_id. > > It also adds a test to confirm that the frame_id will be the same, > regardless of using the epilogue unwinder or not, thanks to Andrew > Burgess. > > Co-Authored-By: Andrew Burgess > > a week or so ago. The test is generating hundreds of new errors on the > various PowerPC processors. From the discussion above, it looks like > you were trying to fix an issue with the amd64 epilogue. Hi Carl, The main point of the patch was fixing the issue with amd64 epilogue unwinding, but the issue itself was that frame IDs aren't consistent throughout the function. With my change in the following patch, if the frame ID is different  at any point, using "reverse next" might consume all the history and stop at the start of the recording, instead of going a single line. This would be applicable to all architectures. > > The patch introduced a new patch to test the amd64 epilogue changes. > Do you expect this new test to run on all other platforms? Yes, we did. See above rationale as to why it is important, but also all instructions in a function should have the same frame id, otherwise all sorts of internal GDB and user confusion can happen. > In addition > to the 575 new errors on Power 10, I see a lots of warnings: > > WARNING: While evaluating expression in gdb_assert: missing operand at _@_ > in expression " _@_== 0x7fffffffc920" > > where the hex value changes for each warning. Still working on sorting > out where the messages come from. I don't think this would be a regression from this patch. Either this was already a problem (just not being triggered) or it was another patch that regressed this. If I clear out my regression backlog, I'll try to help you figure out what is going on. > > The other thing I notice in the gdb/testsuite/gdb.base/unwind-on-each- > insn.exp file is that you set a break point in function foo with the > command: gdb_breakpoint "*foo" > > The use of breakpoint on *function is problematic on Power as discussed > earlier. The use of *foo will set the breakpoint on the remote > breakpoint which will not get hit in this test on PowerPC. I don't see > why you chose to use *foo instead of foo? I don't see anything in the > test that relies on the prolog where you would need the address of the > function before the prolog. I only see references to the epilog of the > function. Right, that is a problem with the test. We do want to test around the epilogue because all instructions have to show the same frame ID, but what could be done instead is breaking on line 23 and using stepi once. > > Anyway, I am trying to figure out how to fix this test to work on > PowerPC. Not sure if there needs to be some similar changes to the > rs6000-tdep.c file similar to the changes in amd64-tdep.c? Any > thoughts you have on the test that would be helpful to getting it to > work on PowerPC, if that is appropriate, or having PowerPC skip this > test would be appreciated. Thanks. The easiest way to check if you need to change rs6000-tdep.c is to record the execution, next over foo and reverse-stepi once, then print the frame-id (maint print frame-id), reverse-step out of the epilogue and print the frame id again. If something doesn't match, you need to fix things. Or you could use the modified test above and see if any printed frame ids is different, if the changes make things work on PPC. I hope this clears things up :) Cheers, Bruno > > Carl > > > >