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 CFD143858C52 for ; Fri, 23 Sep 2022 09:13:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFD143858C52 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-7-kZgJBTCvPze_-9mO4LsDBg-1; Fri, 23 Sep 2022 05:13:27 -0400 X-MC-Unique: kZgJBTCvPze_-9mO4LsDBg-1 Received: by mail-wm1-f70.google.com with SMTP id c129-20020a1c3587000000b003b5152ebf93so262595wma.2 for ; Fri, 23 Sep 2022 02:13:27 -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:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=QdfdzduBGiYgqR9jomZ+UkV2hN9OpTDyYr1Oc//OLDI=; b=JfUWxNuWSgDxHvfwPeKhu5g36yfnsB456hUab/FtDG3IVTgyp4J6d4Yv1JsvKVvXX8 9OGnNpzLtIhuuTxRPQH6Qxo3CmBegDIXO9mihun0iNX5UurcTydufr8JYRn/VbL6NOa/ x25WG3JrfgyTcYhtkGa01ogIIm/qBUbrUnIyQ3KncH+9xTyppyKivEEIU0fongHGxpsF wVuYcv/TlgEtJX+jwieS8h8RuZXjtc9wjgfckWdqqJDYiHMGDmZDSvvyXaCsyzH7C/mb hc/cijH3jMu6dEEwvu5If5LD+r3/yMM5RMw3H4ORxgU+RHaRUJd1sXfhpoEZU4un7WAz mvjA== X-Gm-Message-State: ACrzQf2HKiMC3R+E9NFFxDezouNCWScwbA8MZTJ5rXxkydK+GMoXs5gC 5E5abAngIiUj2ATOQk045qnTSB7PpuYdBhJPvQCgCFAtvR/6UMZWaiymfc65uHiJm7KBGOgU8E8 DMD/S1LCmX8bf9/oicdZCFuJ6GhGWZa+3mh9Q4issnQB3iW7e9z8XHT/PWmF932zvyqLPuWzm X-Received: by 2002:a05:600c:1c8e:b0:3b4:9247:7ecc with SMTP id k14-20020a05600c1c8e00b003b492477eccmr5291078wms.40.1663924405613; Fri, 23 Sep 2022 02:13:25 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6nOvRIZRg99Jdkm4QKD0JfzeXbIJoqwHH64yCnQyK7i2Hj7dUCslDsuas2Za6qJePbsZjM0w== X-Received: by 2002:a05:600c:1c8e:b0:3b4:9247:7ecc with SMTP id k14-20020a05600c1c8e00b003b492477eccmr5291055wms.40.1663924405249; Fri, 23 Sep 2022 02:13:25 -0700 (PDT) Received: from [192.168.0.45] (ip-213-220-232-121.bb.vodafone.cz. [213.220.232.121]) by smtp.gmail.com with ESMTPSA id z5-20020a5d6405000000b0022af9555669sm8154799wru.99.2022.09.23.02.13.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 02:13:24 -0700 (PDT) Message-ID: Date: Fri, 23 Sep 2022 11:13:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp To: gdb-patches@sourceware.org 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: 7bit X-Spam-Status: No, score=-6.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_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 23 Sep 2022 09:13:30 -0000 On 22/09/2022 20:23, Carl Love via Gdb-patches wrote: > GDB community: > > There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and > gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar > reasons on PowerPC. It appears to me that the issues are with the > tests and not with gdb itself. Both tests set breakpoints on *func > where func is a function in the source file. This is the fundamental > issue with both tests. > > The test gdb.reverse/finish-reverse-bkpt.exp has the comment: > > gdb_test "tbreak void_func" \ > "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ > "set breakpoint on void_func" > gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" > > # We stop at the brekapoint on void_func, but breakpoint on > # *void_func will be set at the same place if function void_func doesn't > # have prologue. One step forward to avoid this. > gdb_test "si" > > gdb_test "break \*void_func" \ > "Breakpoint $decimal at .*" \ > "set breakpoint at void_func's entry" > > The comment about break point on void_func and breakpoint on *void_func > being the same if there is no prolong is not true for all > architectures. Specifically PowerPC uses local and global entry > points. The statement "break *foo" sets the breakpoint at the address > of the first instruction in the function where as "break foo" sets the > breakpoint at the beginning of the function, i.e. after the prolog > following the local entry point. Specifically for this test the > PowerPC assembly code is as follows: > > void void_func () > { > 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, > location of break *void_func > 10000690: 00 7f 42 38 addi r2,r2,32512 > 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point > 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog > 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog > void_test = 1; /* VOID FUNC */ > 100006a0: 00 00 00 60 nop <- location of break void_func > 100006a4: 58 81 22 39 addi r9,r2,-32424 > 100006a8: 01 00 40 39 li r10,1 > .... > > The test fails on PowerPC because the reverse execution never hits the > breakpoint at *void_func because the function is called using the local > entry point. Thus gdb returns to the caller after it reaches the local > entry point at address 10000694. It does not continue executing back > to the global entry point. The global entry point is only used in > special cases when the Table of Contents (TOC) pointer is not already > setup in r2. > > The question is how to fix the test in general? > > 1) Changing the breakpoint on *void_func to void_func will cause both > breakpoints to be the same regardless if there is a prolog. That > change would seem to invalidate the point of the test? > > 2) Disable the test for architectures where the assumption breakpoint > on foo and breakpoint on *foo is the same except for a prolog. The > downside is we are missing testing of some gdb functionality. Is there any way you can guarantee that the function will be called through the global entry point? Not just because this is the obvious solution, but because this would increase test coverage in GDB, seeing how reverse behaves on both possible entry points. Another possibility would be to change the underlying GDB mechanism, and make `break *foo` place the breakpoint at the local entry point, since it seems to pass by the local entry point regardless of where it actually enters. From what I understand about reverse debugging, GDB already has to do something similar to reverse-next over functions, so it should be a doable solution. A third possibility is trying to get the local entry point through disassembling the code and using `break *0xdeadbeef` instead. This would be the least intrusive solution, but I know nothing about different function entrypoints, so it might be too much work to be worth it. > > Is there another way to fix this test to run correctly on PowerPC? > > > The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because > it does a break on *callee. Specifically, > > set lineno [gdb_get_line_number "STEP INTO THIS CALL"] > gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" > > gdb_test "b \*callee" "" "set breakpoint at callee's entry" > > set bpnum [get_integer_valueof "\$bpnum" 0] > gdb_test "reverse-next" \ > "Breakpoint $bpnum, callee.*" \ > "reverse-next over call trips user breakpoint at function entry" > > gdb_test "up" \ > ".*NEXT OVER THIS CALL.*" \ > "stopped at the right callee call" > > In this case, it looks to me like changing the gdb_test to callee > instead of *callee doesn't break the point of the test. Making the > change on PowerPC fixes the test. > > Does anyone see any issues with changing the breakpoint from *callee to > calle for this test? I think it does invalidate the test, because GDB will place a step-resume breakpoint at *callee, and the test wants specifically to look at a user breakpoint at the same instruction. Cheers, Bruno > > Thanks for the input and help fixing these tests on PowerPC. > > Carl Love >