From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 5419C3846020 for ; Mon, 5 Jul 2021 11:26:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5419C3846020 Received: by mail-pj1-x1032.google.com with SMTP id p4-20020a17090a9304b029016f3020d867so11594262pjo.3 for ; Mon, 05 Jul 2021 04:26:45 -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:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pOAc6QPNaQskw4mQt+wUcm2I9lrVadRUN3t/vAAsEMw=; b=jJPrUFRk5UKmSMxCv9uXAd1pUl9ki4gpUbsaW5tR7Pu4wusMmarexhCjS2KuCO4Pat nMbWBgePHUot0ey28hnSo/J+/l3U9bRtiYethdXz6G6mmz7PyFOVSWcOiyK9HTOp4m9B 3UmIUpC7De7WmFswZintYK9FWv5FbtzACkD6JCRsD+Rc66FfBie7pV0jatpQ6ZE5geSK 4MJwRB007Za8qPJVkQyev63jhE42Sy1STjmpYmoJdVrQyLJviv9QvL5LHP3K0FfmfmDF VIFyaprgakDYJyR4xNQKjDDt/d3tLbGG42U40m07d23JAI5grOjO4ntfts7YXzE2YUH9 lqEw== X-Gm-Message-State: AOAM531UXwvOMZQUx7DEZ0+5SyDsDVUO8bEHbdySFtjxsS0XWiwT07/o TjJ5IpLwbSRgFSBcX3rdlDz754+/zmlVEw== X-Google-Smtp-Source: ABdhPJyK5OY7G1v7JtorPLCxaL+TKG/SVepWTTHhnaOrvpY5MvNIr4pT6AInh4pbnb9fWX7asQmouA== X-Received: by 2002:a17:90a:4586:: with SMTP id v6mr14865561pjg.36.1625484404308; Mon, 05 Jul 2021 04:26:44 -0700 (PDT) Received: from [192.168.1.88] (187-14-114-195.user3p.veloxzone.com.br. [187.14.114.195]) by smtp.gmail.com with ESMTPSA id ay3sm10798275pjb.38.2021.07.05.04.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jul 2021 04:26:43 -0700 (PDT) Subject: Re: GDB reverse execution question To: Carl Love , gdb@sourceware.org Cc: Rogerio Alves , Ulrich Weigand References: <2915ed3bce4756d4b6291ae3bf84a8b4a9ce67a7.camel@us.ibm.com> From: Luis Machado Message-ID: <0581aed7-5fbb-4764-d6fa-ac6a0573044e@linaro.org> Date: Mon, 5 Jul 2021 08:26:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <2915ed3bce4756d4b6291ae3bf84a8b4a9ce67a7.camel@us.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 11:26:47 -0000 Does the following fix the problem for you? https://sourceware.org/pipermail/gdb-patches/2021-February/175678.html On 7/2/21 3:38 PM, Carl Love via Gdb wrote: > GCC maintainers: > > I am looking into some GDB regression test failures for reverse mode. > The specific test I am currently looking at is > gdb/testsuite/gdb.reverse/step-reverse.exp. I am running the test on a > Power 9 machine with the test compiled with two different versions of > the gcc compiler. > > The test runs fine using the distro compiler /usr/bin/gcc which is gcc > version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04). > > The issue occurs with a more recent build I have gcc version 10.3.1. > where the test fails. > > Both of the compilers generate the same instruction sequences but the > addresses of the assembly instructions differ slightly. Note, the > tests are done with the default optimization for gcc. > > Inintially the test executes "forward", with record enabled, thru a > couple of functions to the line in main with the label "FINISH TEST". > The C code statement consists of five assembly instructions as shown > below where I have put in generic addresses 1 to 7 as the actuall > addresses differ slightly for the output of the two compilers: > > /* Test that "step" doesn't */ > callee(); /* STEP INTO THIS CALL */ > 1: 9bc: c9 fe ff 4b bl 884 > > /* Test "stepi" */ > a[5] = a[3] - a[4]; /* FINISH TEST */ forward execution stops at this C code line > 2: ce 01 5f e9 lwa r10,460(r31) pc is here, step reverse (distro compiler) > 3: d2 01 3f e9 lwa r9,464(r31) > 4: 50 50 29 7d subf r9,r9,r10 New gcc compiler, reverse step from FINISH TEST > only gets to here not the previous > source code line > 5: b4 07 29 7d extsw r9,r9 > 6: d4 01 3f 91 stw r9,468(r31) pc is here for the "newer gcc compiler" > > callee(); /* STEPI TEST */ > 7: b1 fe ff 4b bl 884 > > So as noted above, the distro test stops with PC at address 2 whereas > the newer gcc stops at address 6. Power used to issue groups of up to 4 > instructions at a time. Not sure that Power 9 still does that. I am > still looking for the details on the instruction issuing on Power 9. > But if it does still issue in groups, that could explain the difference > in the PC given the different instruction addresses. I only mention > all this as it is something of note but I don't think is the real > problem. > > The issue occurs when the test switches to reverse and then does a > step, in the reverse direction. In the case of the distro compiler > which is at address 2, the step, in the reverse direction, stops in the > previous line of C code. However, with the newer gcc the reverse step > from address 6 only gets to address 4 which is still in the "FINISH > TEST" C code line. The gdb test fails because the step is not at the > "STEP INTO THIS CALL" C code line as is expected. > > I have been reading the gdb code in gdb/reverse.c and gdb/record-full.c > etc. Recording stores the register and memory changes for each executed > instruction. What I can't find is anything that records the > association of instructions to C code lines. So when gdb does a > reverse "step" how does it know how many assembly instructions to undo? > I believe gdb uses the debug info to figure out where the next > instruction. Don't know where/how this is done in the forward > direction. Again, where/how would gdb make the determination in the > reverse direction to decide where to stop? I have not been able to > determine that in the code for doing reverse execution that I have been > studying. > > The test fails because gdb doesn't unroll enough instructions to get to > the previous source line when the PC is at address 6. I am wondering > if someone can help me understand how gdb determins where/how to stop > when doing a reverse step? > > Thanks for the help. > > Carl Love >