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 6DAEB3858C50 for ; Tue, 29 Mar 2022 13:38:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6DAEB3858C50 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-484-feYwQr37PZiIA2I-K-3Mig-1; Tue, 29 Mar 2022 09:38:31 -0400 X-MC-Unique: feYwQr37PZiIA2I-K-3Mig-1 Received: by mail-wr1-f71.google.com with SMTP id 15-20020adf808f000000b00203e488fa4eso5046046wrl.3 for ; Tue, 29 Mar 2022 06:38:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=h58iWOuyPQ7+q8AY2z8FPfWn2Xj53HeBGDTwbHkVdbw=; b=a0Hi+kMOrn0prPThVud4Ty++ocg/pKlKght45qaHPk+72/GDu7tYsLce1tenyry81z QiZ39axS+L+quTBk/Jf7X3NALZYdnYUH9iYRDLK64BHUYFoeJUf1P9pb5Bf4BUyUHvLu l2qiTdygJy5i+/c3gVpSciUuzfTfgtJrg1nOD9rxcKF3HbArP5ayyS9fwOYjXYVk8l4F ZmMRkVIERnL3IzaIMYA05jSIj4oHxTYPJzI38TJDVBqy0wDISc2OhSRDGEHyyYBGWJyc dkP+7dkffgJqrkVWN0KOwTVRYKdrauj7ffMfRd6xmR3XSF3je88Zn5dlAdcj3s9TSCqC 9V4g== X-Gm-Message-State: AOAM533UrjGMbbsjnc8TkNrYdZB30eQZkiVfbnmn1fHwo4QTfS3UYN3V d1nBJ5u0/mCbsUswsTgdzAEs2x13Ja70j+UGn/zfT19/Dl99US5ef6p80JREVvM+h2xGDXIRPxV Mb2GxDfobzptFut8CMtkUng== X-Received: by 2002:a1c:e916:0:b0:37c:f44f:573 with SMTP id q22-20020a1ce916000000b0037cf44f0573mr6973880wmc.179.1648561109751; Tue, 29 Mar 2022 06:38:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrpfQiJT8hbGvqAX8FOSLpmFt2m4c6QEzs3NkQCXwjkmWwUBcXKFF/j3wRXg9PW8c9/2mwVg== X-Received: by 2002:a1c:e916:0:b0:37c:f44f:573 with SMTP id q22-20020a1ce916000000b0037cf44f0573mr6973849wmc.179.1648561109462; Tue, 29 Mar 2022 06:38:29 -0700 (PDT) Received: from localhost (host86-169-131-113.range86-169.btcentralplus.com. [86.169.131.113]) by smtp.gmail.com with ESMTPSA id y15-20020a05600015cf00b00203e324347bsm17426065wry.102.2022.03.29.06.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 06:38:28 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Cc: Andrew Burgess Subject: Re: [PATCHv3] gdb/python: add gdb.format_address function In-Reply-To: <7afdf076-59f9-4655-0dc8-1ac2f9d07e70@polymtl.ca> References: <20220304105031.2706582-1-aburgess@redhat.com> <20220307123317.3966024-1-aburgess@redhat.com> <87o81yruo9.fsf@redhat.com> <87ils4sn3n.fsf@redhat.com> <7afdf076-59f9-4655-0dc8-1ac2f9d07e70@polymtl.ca> Date: Tue, 29 Mar 2022 14:38:27 +0100 Message-ID: <87pmm4anfw.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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-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: Tue, 29 Mar 2022 13:38:36 -0000 Simon Marchi writes: >> Hi Simon, >> >> Sorry for that. I can't reproduce these failures, but I suspect I know >> what's going on. Could you try the patch below please and confirm that >> this fixes the issues. >> >> Many thanks, >> Andrew >> >> --- >> >> commit d6eb0c69d3919a1b3862d29c788415ca9f7bbeb4 >> Author: Andrew Burgess >> Date: Wed Mar 23 15:23:47 2022 +0000 >> >> gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp >> >> The test gdb.python/py-format-address.exp, added in commit: >> >> commit 25209e2c6979c3838e14e099f0333609810db280 >> Date: Sat Oct 23 09:59:25 2021 +0100 >> >> gdb/python: add gdb.format_address function >> >> Included 3 copy & paste errors where the wrong address was used in the >> expected output patterns. >> >> The test compiles two almost identical test binaries (one function >> changes its name, that's the only difference), if the two binaries are >> laid out the same by the compiler, and loaded at the same locations in >> memory, then the two addresses would have been the same. However, >> this is not the case for everyone, and so some folk were seeing test >> failures: >> >> https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html >> >> This commit fixes the errors by using the correct addresses. > > Hi Andrew, > > I looked into this separately because I failed to see your message. In > the end I came up with the same change, but the reason the addresses are > different is that the executables are PIE. Inferior 1 is running, so > the function address is relocated: > > print /x &foo^M > $2 = 0x555555555129^M > > Inferior 2 is not running, so the function address is unrelocated: > > print /x &bar^M > $3 = 0x1129^M > > So, the patch LGTM, but you can clarify the commit message if you want. I pushed the patch below. This updates the commit message, but also, I pass the 'nopie' option when compiling the test binaries, which should make the test more useful (the addresses should now be the same). Thanks, Andrew --- commit 4daa9f295d07917610f0972e0cd45df8c51e69a2 Author: Andrew Burgess Date: Wed Mar 23 15:23:47 2022 +0000 gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp The test gdb.python/py-format-address.exp, added in commit: commit 25209e2c6979c3838e14e099f0333609810db280 Date: Sat Oct 23 09:59:25 2021 +0100 gdb/python: add gdb.format_address function included 3 copy & paste errors where the wrong address was used in the expected output patterns. The test compiles two almost identical test binaries (one function changes its name, that's the only difference), two inferiors are created, each inferior using one of the test binaries. We then take the address of the name changing function in both inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests are carried out using these addresses. What we're checking for is that symbols 'foo' and 'bar' show up in the correct inferior, and that (as this test is for a Python API feature), the user can have one inferior selected, but ask about the other inferior, and see the correct symbol in the result. The hope is that the two binaries will be laid out identically by the compiler, and that 'foo' and 'bar' will be at the same address. This is fine, unless the executable is compiled as PIE (position independent executable), in which case there is a problem. The problem is that though inferior 1 is set running, the inferior 2 never is. If the executables are compiled as PIE, then the address in the inferior 2 will not have been resolved, while the address in the inferior 1 will have been, and so the two addresses we use in the tests will be different. This issue was reported here: https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html The first part of the fix is to use the correct address variable in the expected output patterns, with this change the tests pass even when the executables are compiled as PIE. A second part of this fix is to pass the 'nopie' option when we compile the tests, this should ensure that the address obtained in inferior 2 is the same as the address from inferior 1, which makes the test more useful. diff --git a/gdb/testsuite/gdb.python/py-format-address.exp b/gdb/testsuite/gdb.python/py-format-address.exp index 5c808299d34..bbfe658c0bb 100644 --- a/gdb/testsuite/gdb.python/py-format-address.exp +++ b/gdb/testsuite/gdb.python/py-format-address.exp @@ -20,6 +20,7 @@ foreach func_name { foo bar } { if {[build_executable "build binary with ${func_name} function" \ "$testfile-${func_name}" $srcfile \ [list debug \ + nopie \ additional_flags=-DFUNCTION_NAME=${func_name}]] == -1} { return -1 } @@ -138,19 +139,19 @@ set bar_addr [get_hexadecimal_valueof "&bar" "UNKNOWN"] # architecture, this should display the 'bar' symbol rather than # 'foo'. gdb_test "python print(\"Got: \" + gdb.format_address($bar_addr))" \ - "Got: $foo_addr " \ + "Got: $bar_addr " \ "gdb.format_address for bar, while inferior 2 is selected" # And again, but this time, specificy the program space and # architecture. gdb_test "python print(\"Got: \" + gdb.format_address($bar_addr, inf2.progspace, inf2.architecture()))" \ - "Got: $foo_addr " \ + "Got: $bar_addr " \ "gdb.format_address for bar, while inferior 2 is selected, pass progspace and architecture" # Reselect inferior 1, and then format an address from inferior 2. gdb_test "inferior 1" ".*" gdb_test "python print(\"Got: \" + gdb.format_address($bar_addr, inf2.progspace, inf2.architecture()))" \ - "Got: $foo_addr " \ + "Got: $bar_addr " \ "gdb.format_address for bar, while inferior 1 is selected, pass progspace and architecture" # Try pasing incorrect object types for program space and architecture.