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 B42B73857022 for ; Thu, 20 Jul 2023 12:01:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B42B73857022 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=1689854474; 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=AXNRdhSLvUSOtZPZZQkfQY6zSO3eXnELtsUrOz9bXZg=; b=ZiuwRkZc740P1UFGACqHHBvTuB27Pwqhp+UGpkXe03uRcYlxb0v6BBbVELhmT6N/byPj9C i7to76ImvShiZL5YDemxfQNvBkUDj6x+pQ4ItN74uteHh22eRNLwYnNRDbJlkvJwvJ+kXi pa0GCiml4f0alM3Fe55f+FV1Z+CIsFI= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-576-2VQNcIpFOHa4JVMjnnbiOg-1; Thu, 20 Jul 2023 08:01:13 -0400 X-MC-Unique: 2VQNcIpFOHa4JVMjnnbiOg-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-403cddf284bso11174571cf.0 for ; Thu, 20 Jul 2023 05:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689854473; x=1690459273; 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=AXNRdhSLvUSOtZPZZQkfQY6zSO3eXnELtsUrOz9bXZg=; b=KUAnFNnTC1S1ZBFJotNARps44cQVWIMSQtotQZKJCBh+CA6ShNFftRLaOLiNwEIwLN zE9teikgnpayI4HI0RJvtr5TYrRekVyG+I8usxVY1lcCtRdEKJ2/f1P11MvsJ9m72CNQ X7nyjjOAPQsjSXDjNfK6ZzZvv7LhcoA/34hlaCDtxdyqDsBwlFq+gcYimlXe3PieUclh mhYW+aZf/FBBQojb2eoOI7V1Js6wYr/fBqoQpqyKdDG6G7wtEkVps0Z9RCPYxQ5eFDqX QYejyw7uoIQ6ws9sDveANZv8fDoK5uuLFtB4nfOmqR/Y2XB84CTiNhLUwtEQMiQ2Pcv6 WK9w== X-Gm-Message-State: ABy/qLbbMeopddBaoGeypDIiNI1EjEzTKRKplW8Hw4omJmWDJQYJ4Rvf e6k+7U4+yPG7HgtGjKhyqshmqbT6Z7FusLJ5PxRk4WX2b6RRTuSgkseM5yIoPjO663YDs/PnrUh +3UcfD/ZdK2XcxSaP7GXK6A== X-Received: by 2002:a05:622a:1990:b0:403:b9ea:7b82 with SMTP id u16-20020a05622a199000b00403b9ea7b82mr27666432qtc.29.1689854473147; Thu, 20 Jul 2023 05:01:13 -0700 (PDT) X-Google-Smtp-Source: APBJJlFWhjZLdxI8slo4zBAukr3aD12kyPjDtH5RpC9iH/h8cX6+0mvL4o8o2PHIStrBCbSy7F5/1A== X-Received: by 2002:a05:622a:1990:b0:403:b9ea:7b82 with SMTP id u16-20020a05622a199000b00403b9ea7b82mr27666402qtc.29.1689854472772; Thu, 20 Jul 2023 05:01:12 -0700 (PDT) Received: from [192.168.0.129] (ip-94-112-225-44.bb.vodafone.cz. [94.112.225.44]) by smtp.gmail.com with ESMTPSA id x21-20020ac87315000000b003f6bbd7863csm249504qto.86.2023.07.20.05.01.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jul 2023 05:01:11 -0700 (PDT) Message-ID: <6c58d4ce-d9ff-e1d9-398b-724859394f22@redhat.com> Date: Thu, 20 Jul 2023 14:01:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp To: Simon Marchi , Carl Love , Tom de Vries , Ulrich Weigand , "gdb-patches@sourceware.org" , "pedro@palves.net" References: <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> <15864a6b87b25c93e99a28149f23138267735f2a.camel@us.ibm.com> <041f62e9f26fd4a536bc90c34f072985582e6237.camel@de.ibm.com> <46c2c756475ba5923d7eed97996632a08285dd42.camel@us.ibm.com> <65861786-069e-53a1-ca17-a525b6629c95@suse.de> <5be0c849abeef84d34a6ff255fb2705ca5dcb035.camel@us.ibm.com> <5e60a837-b21c-011f-c94e-e8bbf7645c5d@simark.ca> <7639de48695d52a806627b0a91979ad2e5fd9b42.camel@us.ibm.com> <9cf51eb9-c731-6f42-ab2b-a37048f25d12@simark.ca> <60c362e6dadd05754907af5f10e6f3c0423e1901.camel@us.ibm.com> <2a1d55cb-118b-d942-b315-a5f2348894f5@simark.ca> <0ab7af40f2f8d1edbceea851c37282a03c830567.camel@us.ibm.com> <90c98190-f8eb-1d64-43ce-8bab67d5caef@simark.ca> From: Bruno Larsen In-Reply-To: <90c98190-f8eb-1d64-43ce-8bab67d5caef@simark.ca> 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=-1.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 28/03/2023 17:38, Simon Marchi wrote: > On 3/28/23 11:17, Carl Love wrote: >> Simon: >> >> On Mon, 2023-03-27 at 21:19 -0400, Simon Marchi wrote: >>> To confirm the theory, I added a: >>> >>> gdb_test "set range-stepping off" >>> >>> somewhere near the beginning of your test, and it makes the test pass >>> with native-gdbserver. >>> >>> If we want recording to work the same with process targets using >>> range-stepping and those that don't, maybe GDB should avoid using >>> range-stepping when the record-full target is in effect? >> We could just update the test to include gdb_test "set range-stepping >> off" with a brief explanation of the issue. This would have a minimal >> impact on performance of this test and no performance degradation for >> any other tests. It sounds like this would fix the issue for just this >> test. >> >> It sounds like disabling range-stepping when record-full is enabled >> would be the more general fix for the issue. Not sure if there are >> other tests where this issue occurs. Doing the more general fix would >> probably have some performance impact on the other tests that need to >> use record-full. I can't really say how much of an impact it would be. > It depends on what the goal is. In general, we try to minimize the > differences in behavior when debugging native vs debugging remote. So, > if we say that it's a bug that the record-full target doesn't see all > the intermediary steps, then putting "set range-stepping off" in that > test would just be papering over the bug. I think the correct thing to > do would be to fix GDB. And yes there will be a performance impact when > using remote debugging + record-full, but if that's what's needed to get > correct behavior... > > Some ideas to implement this: > > - Add a target method supports_range_stepping, record-full would > implement it and return false. The default would be true. > - record-full's resume method could clean the resumed thread's > may_range_step flag. > > I'm open to other ideas. Note that we don't want to disable range > stepping for other record implementations (only btrace, currently), I > don't think that one is affected by the problem (the hardware should > record all intermediary steps in any case). > > Simon > Sorry for possibly necromancing this thread, but I decided to look into gdb.reverse failures when testing with clang and the same issue occurs as with gdbserver. I decided to take a look and re-read old messages and what Pedro actually said in that thread is a bit confusing, because there were multiple intertwined issues being discussed. Looking at this email (https://sourceware.org/pipermail/gdb-patches/2023-January/196130.html) he does mention that GDB should not stop in the same line when a reverse-step or reverse-next is used. Because of that, I believe that the behavior that the test expects is actually incorrect, and we should try and fix this. Looking at the state of the program when it is compiled with GCC we get: ➜  gdb ./gdb -q testsuite/outputs/gdb.reverse/finish-reverse-next/finish-reverse-next -ex start -ex record Reading symbols from testsuite/outputs/gdb.reverse/finish-reverse-next/finish-reverse-next... Temporary breakpoint 1 at 0x401176: file /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.revers3/finish-reverse-next.c, line 76. Starting program: /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.reverse/finish-reverse-next/finish-reverse-next [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde78)     at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:76 76        int (*funp) (int, int) = &function1; (gdb) until 83 main (argc=1, argv=0x7fffffffde78)     at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:83 83        function1 (a, b);   // CALL VIA LEP (gdb) n 86        a = 10; (gdb) rs function1 (a=1, b=5)     at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:70 70      } (gdb) reverse-finish Run back to call of #0  function1 (a=1, b=5)     at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:70 0x0000000000401196 in main (argc=1, argv=0x7fffffffde78)     at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:83 83        function1 (a, b);   // CALL VIA LEP (gdb) maint info line-table             (snip) 15     81     0x0000000000401185 0x0000000000401185 Y 16     83     0x000000000040118c 0x000000000040118c Y 17     86     0x000000000040119b 0x000000000040119b Y (gdb) disas /s Dump of assembler code for function main:       (snip) 83        function1 (a, b);   // CALL VIA LEP    0x000000000040118c <+37>:    mov    -0x10(%rbp),%edx    0x000000000040118f <+40>:    mov    -0xc(%rbp),%eax    0x0000000000401192 <+43>:    mov    %edx,%esi    0x0000000000401194 <+45>:    mov    %eax,%edi => 0x0000000000401196 <+47>:    call   0x40112c We can see that we have stopped at the right instruction, but it isn't mapped to any line number directly. If we reverse-next from there: 82 83        function1 (a, b);   // CALL VIA LEP => 0x000000000040118c <+37>:    mov    -0x10(%rbp),%edx    0x000000000040118f <+40>:    mov    -0xc(%rbp),%eax    0x0000000000401192 <+43>:    mov    %edx,%esi    0x0000000000401194 <+45>:    mov    %eax,%edi    0x0000000000401196 <+47>:    call   0x40112c We at at an address that _is_ mapped in the line table. So my guess is that the code setting up the reverse-next or reverse-step is failing to figure out our current line (83) so cant properly setup a stepping range, GDB would reverse step a single instruction, but since that leaves us in a place that is not marked IS_STMT, GDB will continue to step until we hit an IS_STMT location, and we end up stopping at the same line twice. For completeness sake, here's what the Clang session looks like: (gdb) reverse-finish Run back to call of #0  0x000000000040117b in function1 (a=1, b=5) at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:69 0x00000000004011c8 in main (argc=1, argv=0x7fffffffde78) at /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.c:83 83        function1 (a, b);   // CALL VIA LEP (gdb) maint info line-table          (snip) 22     80     0x00000000004011b4 0x00000000004011b4 Y 23     81     0x00000000004011bb 0x00000000004011bb Y 24     83     0x00000000004011c2 0x00000000004011c2 Y 25     83     0x00000000004011c5 0x00000000004011c5 26     83     0x00000000004011c8 0x00000000004011c8 27     86     0x00000000004011cd 0x00000000004011cd Y (gdb) disas /s          (snip) 81        b = 5;    0x00000000004011bb <+43>:    movl   $0x5,-0x18(%rbp) 82 83        function1 (a, b);   // CALL VIA LEP    0x00000000004011c2 <+50>:    mov    -0x14(%rbp),%edi    0x00000000004011c5 <+53>:    mov    -0x18(%rbp),%esi => 0x00000000004011c8 <+56>:    call   0x401140 (gdb) rn 81        b = 5; Basically, the best way to fix this solution is to get reverse-next and reverse-step to properly figure out the stepping range and not have a reverse-next that ends up in the same line -- Cheers, Bruno