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.129.124]) by sourceware.org (Postfix) with ESMTPS id 4C2EE3858D1E for ; Tue, 2 May 2023 14:31:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C2EE3858D1E 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=1683037860; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rX0cTi9pM+Hmazp/8k6devJEKOk6khzQ8BnQET7Wl0s=; b=SBxfWgs848d35xcAafrmVB73rsrpCF3RcZm8jd1BAI2HKBAi/KTL/hSNKFHhPX8ujyOOXe 1Kb1EHaXlMiZLKZ+LecnjGdFptj4TLkZyDdDsm8pOVOG2Ho/bgjpNSaicYOMA5m0dBSKlX 1qG6FO5AU8D0uPYGyAPs6kUTKhz3MrU= Received: from mail-qt1-f199.google.com (209.85.160.199 [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-62-kG9djTcGO2GDlkOrwYOnBA-1; Tue, 02 May 2023 10:28:08 -0400 X-MC-Unique: kG9djTcGO2GDlkOrwYOnBA-1 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-3ef3ca5b5afso51453801cf.0 for ; Tue, 02 May 2023 07:27:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683037672; x=1685629672; h=content-transfer-encoding:in-reply-to:from:references: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=rX0cTi9pM+Hmazp/8k6devJEKOk6khzQ8BnQET7Wl0s=; b=iyVNn2d9s/ZPGbV55/tmFhn9TRkTs1kvZRp8JO4fz+kQ6IZ44OOr5i2j1WJk76dXJ9 f371bobqlJkIdkQhe6rpH5Z4AAtm0Vc2FSDKMaJsweRKUFFki/rLfKtjCvW+ohLz4msd ykoZFrqpR+l6ig3Dip4bJUo9l2qxGMS0/A1uzXPxhTrCKVFOWtFyHQE6fQOmTapQkB13 YeQgLZo+V61PlGZ2Yd6h117+0xWbDVR4XguEtt2q+qoozx+1At6sEjy9LXQY+aOcmHJR krpLRIQ6aXYkv+uzrmqqoNr04GmVk+XynAp9QUvW/Imt/FmBRGjJgIIFafdKPL+PuNO5 3nwA== X-Gm-Message-State: AC+VfDxw1sJOuSngo/kVAMMNXClblpnukDfJXfqMd2BnU4WJlGB27PcE oV3Q/XN4E7bwFEnTkNMWmAnhdC9UBddWF6CLR8M1Axtm+LpbT2S+XDwC/x4x80q/c9qGfbIJdcj wls6YhHJJ56a3uiRue3O/a/tCSNQO4Q== X-Received: by 2002:ac8:7dc6:0:b0:3bf:d8b6:4ca1 with SMTP id c6-20020ac87dc6000000b003bfd8b64ca1mr29518956qte.28.1683037671888; Tue, 02 May 2023 07:27:51 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4guat/VA9GAccFWTlwXnu8qqSOsmcn2lRqHuOSdAyXMreGqDTlj0EiguxvSbQ4UJwcBPNSsw== X-Received: by 2002:ac8:7dc6:0:b0:3bf:d8b6:4ca1 with SMTP id c6-20020ac87dc6000000b003bfd8b64ca1mr29518926qte.28.1683037671658; Tue, 02 May 2023 07:27:51 -0700 (PDT) Received: from [192.168.0.45] (ip-94-112-225-44.bb.vodafone.cz. [94.112.225.44]) by smtp.gmail.com with ESMTPSA id p3-20020a05620a22a300b007465ee178a3sm9668951qkh.96.2023.05.02.07.27.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 May 2023 07:27:51 -0700 (PDT) Message-ID: Date: Tue, 2 May 2023 16:27:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH] gdb/record-full: disable range stepping when resuming threads To: Simon Marchi , gdb-patches@sourceware.org References: <20230427185407.203300-1-simon.marchi@efficios.com> From: Bruno Larsen In-Reply-To: <20230427185407.203300-1-simon.marchi@efficios.com> 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: 7bit X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 27/04/2023 20:54, Simon Marchi via Gdb-patches wrote: > I see these failures, when running with the native-gdbserver of > native-extended-gdbserver boards: > > Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ... > FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body > FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body > FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body > FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body > > Let's use this simpler program to illustrate the problem: > > int main() > { > int a = 362; > a = a * 17; > return a; > } > > It compiles down to: > > int a = 362; > 401689: c7 45 fc 6a 01 00 00 movl $0x16a,-0x4(%rbp) > a = a * 17; > 401690: 8b 55 fc mov -0x4(%rbp),%edx > 401693: 89 d0 mov %edx,%eax > 401695: c1 e0 04 shl $0x4,%eax > 401698: 01 d0 add %edx,%eax > 40169a: 89 45 fc mov %eax,-0x4(%rbp) > return a; > 40169d: 8b 45 fc mov -0x4(%rbp),%eax > > When single stepping these lines, debugging locally, while recording, > these are the recorded instructions (basically one for each instruction > shown above): > > (gdb) maintenance print record-instruction 0 > 4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00 > Register rip changed: (void (*)()) 0x40169a > (gdb) maintenance print record-instruction -1 > Register rax changed: 5792 > Register eflags changed: [ PF AF IF ] > Register rip changed: (void (*)()) 0x401698 > (gdb) maintenance print record-instruction -2 > Register rax changed: 362 > Register eflags changed: [ PF ZF IF ] > Register rip changed: (void (*)()) 0x401695 > (gdb) maintenance print record-instruction -3 > Register rax changed: 4200069 > Register rip changed: (void (*)()) 0x401693 > (gdb) maintenance print record-instruction -4 > Register rdx changed: 140737488346696 > Register rip changed: (void (*)()) 0x401690 > (gdb) maintenance print record-instruction -5 > 4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00 > Register rip changed: (void (*)()) 0x401689 > (gdb) maintenance print record-instruction -6 > Not enough recorded history > > But when debugging remotely: > > (gdb) maintenance print record-instruction 0 > Register rdx changed: 140737488346728 > Register rip changed: (void (*)()) 0x401690 > (gdb) maintenance print record-instruction -1 > 4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00 > Register rip changed: (void (*)()) 0x401689 > (gdb) maintenance print record-instruction -2 > Not enough recorded history > > In this list, we only have entries for the beginning of each line. This > is because of the remote target's support for range stepping. The > record-full layer can only record instructions when the underlying > process target reports a stop. With range stepping, the remote target > single-steps multiple instructions at a time, so the record-full target > doesn't get to see and record them all. > > Fix this by making the record-full layer disable range-stepping > before handing the resume request to the beneath layer, forcing the > remote target to report stops for each instruction. > > Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d > --- > gdb/record-full.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/gdb/record-full.c b/gdb/record-full.c > index 15c5b7d682ed..026c309b674c 100644 > --- a/gdb/record-full.c > +++ b/gdb/record-full.c > @@ -1094,6 +1094,13 @@ record_full_target::resume (ptid_t ptid, int step, enum gdb_signal signal) > /* Make sure the target beneath reports all signals. */ > target_pass_signals ({}); > > + /* Disable range-stepping, forcing the process target to report stops for > + all executed instructions, so we can record them all. */ > + process_stratum_target *proc_target > + = current_inferior ()->process_target (); > + for (thread_info *thread : all_non_exited_threads (proc_target, ptid)) > + thread->control.may_range_step = 0; > + > this->beneath ()->resume (ptid, step, signal); > } > } Hey! Nice catch on this one, with this change you also managed to fix record/29745 (https://sourceware.org/bugzilla/show_bug.cgi?id=29745). For future improvement, I'm wondering: is gdbserver aware that the execution is being recorded at all? That way it could record the execution by itself and once the stop is reported, it sends the recorded instructions (which I hope should be faster). I'm asking before adding it to my backlog, just in case it is very difficult to do. -- Cheers, Bruno