From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ajshKfl5U2SCTz4AWB0awg (envelope-from ) for ; Thu, 04 May 2023 05:25:13 -0400 Received: by simark.ca (Postfix, from userid 112) id 9CF2C1E11B; Thu, 4 May 2023 05:25:13 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=yQuKBcL7; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C0F1C1E0D6 for ; Thu, 4 May 2023 05:25:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 434593858D33 for ; Thu, 4 May 2023 09:25:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 434593858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1683192312; bh=vdc38yuMyHGqUhVUKGyU6+Pgx9ySjkyIrdg8lKjMXO0=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=yQuKBcL7qEev9aZekmFBWntPMa0cXSslb+/mAM9v+ZsV0R3oM7Vd09zIsdaQ2bfVc Or2cQ6o88pxXKsmNucO6xzFqPr0dcfmW2sEzzK58T/OzfaDX22UbdYf3c8pf4MdDLA IV4muNbSB8xjEoZ2gowgH7/38rrEi25ch+kYCqG8= 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 4412C3858D28 for ; Thu, 4 May 2023 09:24:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4412C3858D28 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-627-pUYa6uT-PTaD9Q_Tmc4EmQ-1; Thu, 04 May 2023 05:24:50 -0400 X-MC-Unique: pUYa6uT-PTaD9Q_Tmc4EmQ-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3f1763fac8bso1601785e9.1 for ; Thu, 04 May 2023 02:24:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683192290; x=1685784290; 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=vdc38yuMyHGqUhVUKGyU6+Pgx9ySjkyIrdg8lKjMXO0=; b=FAcsBeCtD95w/lfl2kQYd6k87jB5SuLm3GdVxtH3K8scMYABhFuI9iitlbUObdMuU/ 1B2FoXeVh/HwYjKn2LXwNRQYRji/FSiIK6z2qHN7Df3I/cMFq9D3upNES6NLgOkAIS9r SFTUoP7eYTTolu9Ch2H3zN1ZhJEKZK7tEBu0C0rvJDgXJhmnGMgJXZnMbfCd7qYBZP81 eF9j4U5LANlkAnXsw6798/sNani+zp2O5ISQC3IAl/UBrPAAIV5pri/J8PwJSoB0Ym0O yBRB3A+xdx8lWLpD4QUWbhIpVAGA2hNvmKxP4KVDcc/LelA1zxnD9SdYrRZCsN5+MoL8 sizA== X-Gm-Message-State: AC+VfDy1bskqWckwxdjlkr79Aa/1jgnyyIpVB+x+til/WtxnFApC56gI 2z3IFj0DoXvYAKM+pBVhEx3YH+saLXHroK6dl8+9iOQemlKpKOVK8egqjEQOXQlUriqfbiJFfJz fDO4bOCAFfUiR0doMHCbG0w== X-Received: by 2002:a5d:414d:0:b0:2ce:a34b:2b0b with SMTP id c13-20020a5d414d000000b002cea34b2b0bmr2290473wrq.28.1683192289797; Thu, 04 May 2023 02:24:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7XD827ZKgVFdbrfRNx7L2kiMUvXXvPruV18nfTOxX03+EEshce+84lQ4BJeLP05TeiBInMlw== X-Received: by 2002:a5d:414d:0:b0:2ce:a34b:2b0b with SMTP id c13-20020a5d414d000000b002cea34b2b0bmr2290456wrq.28.1683192289432; Thu, 04 May 2023 02:24:49 -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 k11-20020a7bc40b000000b003f173a2b2f6sm4259052wmi.12.2023.05.04.02.24.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 May 2023 02:24:48 -0700 (PDT) Message-ID: Date: Thu, 4 May 2023 11:24:47 +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] Fix reverse stepping multiple contiguous PC ranges over the line table. To: Carl Love , gdb-patches@sourceware.org, Ulrich Weigand , pedro@palves.net Cc: luis.machado@arm.com References: <74630f1ccb6e9258ae60682105ee5490726fb255.camel@us.ibm.com> <46d73c69-9168-44c6-b515-23dd893fc0eb@redhat.com> <7c596ccfc69b237a6094ead018f4a0b38b82a632.camel@us.ibm.com> In-Reply-To: <7c596ccfc69b237a6094ead018f4a0b38b82a632.camel@us.ibm.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: 8bit 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: , From: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 04/05/2023 04:55, Carl Love wrote: > Bruno: > > On Wed, 2023-05-03 at 11:53 +0200, Bruno Larsen wrote: >> On 27/04/2023 22:59, Carl Love wrote: > >>> + >>> +# This test uses the gcc no-column-info command. >> Correct me if I'm wrong, but it seems to me that the other test is a >> more generic version of this one, so this test could check for a gcc >> recent enough to support this feature, instead of just generically >> gcc. >> That said, gcc added it on version >> 7( >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0029b929c9719a >> ), is it >> old enough that we don't care? > GCC supports line tables, I don't know that clang or other compilers > do. So all we really need is to check for gcc. The line table stuff > was added a long time ago so not sure that we really need to check for > version 7 at this point. So just checked that we are using gcc. The > "other test" func-map-to-same-line.exp expects the line table so it > should probably also be checking that we are using gcc. GCC 7.1 (first gcc 7 release) was on May 2nd 2017, almost exactly 6 years ago, and there was a gcc 6.8 release in october 2018. I don't know if 5 years is long enough to assume that everyone has abandoned the old version (especially seeing as we sometimes test for gcc 4 or 3, but that might just be old cruft). That said, it's not a blocker for me, so /shrug Also, clang will have line tables - otherwise almost nothing on our test suite would work. It doesn't have column info, though, which is why I'm fine with it being ignored in the test that uses -gno-column-info. > >>> +if ![is_c_compiler_gcc] { >>> + unsupported "gcc is required for this test" >>> + return 0 >>> +} >>> + >>> +set srcfile func-map-to-same-line.c >>> +set executable func-map-to-same-line >>> + >>> +set options [list debug additional_flags=-gno-column-info] >>> + >>> +if {[build_executable "failed to prepare" $executable $srcfile >>> $options] == -1}\ >>> + { >>> + return -1 >>> +} >>> + >>> +clean_restart $executable >>> + >>> +runto_main >>> +set target_remote [gdb_is_target_remote] >>> + >>> +if [supports_process_record] { >>> + # Activate process record/replay. >>> + gdb_test_no_output "record" "turn on process record for test1" >>> +} >>> + >>> +# This regression test verifies the reverse-step and reverse-next >>> commands >>> +# work properly when executing backwards thru a source line >>> containing >>> +# two function calls on the same source line, i.e. func1 (); func2 >>> (); >>> +# This test is compiled so the dwarf info not contain the line >>> table >>> +# information. >>> + >>> +# Test 1, reverse-next command >>> +# Set breakpoint at the line after the function calls. >>> +set bp_start_reverse_test [gdb_get_line_number "START REVERSE >>> TEST" $srcfile] >>> +gdb_breakpoint $srcfile:$bp_start_reverse_test temporary >>> + >>> +# Continue to break point for reverse-next test. >>> +# Command definition: reverse-next [count] >>> +# Run backward to the beginning of the previous line executed in >>> the current >>> +# (innermost) stack frame. If the line contains function calls, >>> they will be >>> +# “un-executed” without stopping. Starting from the first line >>> of a function, >>> +# reverse-next will take you back to the caller of that >>> function, before the >>> +# function was called, just as the normal next command would >>> take you from >>> +# the last line of a function back to its return to its caller 2 >>> . >>> + >>> +gdb_continue_to_breakpoint \ >>> + "stopped at command reverse-next test start location" \ >>> + ".*$srcfile:$bp_start_reverse_test\r\n.*" >>> + >>> +# The reverse-next should step all the way back to the beginning >>> of the line, >>> +# i.e. at the beginning of the func1 call. >>> +gdb_test "reverse-next" ".*func1 \\(\\); func2 \\(\\);.*" \ >>> + "reverse-next to line with two functions" >>> + >>> +# A reverse-step should step back and stop at the beginning >>> +# of the previous line b = 2, i.e. not in func1 (). >>> +gdb_test "reverse-step" ".*b = 2;.*" \ >>> + "reverse-step to previous line b = 2" >> The point of this test is to confirm that we are at the very first >> instruction of the line, right? So I would think it is better to do >> a >> reverse-stepi here, to make sure that even walking a single >> instruction >> we reach a different line. > Yes, we should be on the first instruction of the line so stepi would > be a better test to prove we are really on the first instruction. > Changed the reverse-step to reverse-stepi. > >> Either that or doing what Pedro did in his >> email: save the PC before executing the line, then do and undo the >> line >> and confirm that PCs match exactly. >>> + >>> + >>> +# Setup for test 2 >>> +# Go back to the start of the function >>> +gdb_test "reverse-continue" "a = 1;" "At start of main, setup for >>> test 2" >>> + >>> +# Turn off record to clear logs and turn on again >>> +gdb_test "record stop" "Process record is stopped.*" \ >>> + "turn off process record for test1" >>> +gdb_test_no_output "record" "turn on process record for test2" >> Since you don't require process record for this test, you can't >> assume >> these to work. I think its better to clean restart and record if the >> process supports recording, this way you're sure to reset history no >> matter the inferior. > No, the test requires process record. If record is not supported, we > can't do reverse execution. That said, doing a "clean restart" and > then record would be another way, probably better way, of clearing the > history. Put in a clean restart rather than turning off/on the > recording to clear the log file. From my understanding, you could have architectures or inferiors that support reverse execution without needing to record, that's why "supports_reverse" and "supports_process_record" are different. However, if you want to restrict this to record-only, that's fine, I just think it should be a requirement at the top of the test, not in the middle of the execution. -- Cheers, Bruno