From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 5593B3856968 for ; Tue, 13 Sep 2022 14:55:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5593B3856968 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 8EE295C2A5; Tue, 13 Sep 2022 14:55:14 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7070A13AB5; Tue, 13 Sep 2022 14:55:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id O1roGdKZIGOuRgAAMHmgww (envelope-from ); Tue, 13 Sep 2022 14:55:14 +0000 Message-ID: <19d06b9f-4886-5f13-80c2-02c4d90f5172@suse.de> Date: Tue, 13 Sep 2022 16:55:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH 2/2] [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le Content-Language: en-US To: Luis Machado , gdb-patches@sourceware.org References: <20220901140905.24562-1-tdevries@suse.de> <20220901140905.24562-2-tdevries@suse.de> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Tue, 13 Sep 2022 14:55:16 -0000 On 9/12/22 12:20, Luis Machado wrote: > On 9/1/22 15:09, Tom de Vries via Gdb-patches wrote: >> In commit cd919f5533c ("[gdb/testsuite] Fix >> gdb.dwarf2/dw2-dir-file-name.exp"), I made >> gdb.dwarf2/dw2-dir-file-name.exp >> independent of prologue analyzers, using this change: >> ... >> -       gdb_breakpoint $func >> +       gdb_breakpoint *$func >> ... >> >> That however caused a regression on ppc64le.  For PowerPC, as >> described in the >> ELFv2 ABI, a function can have a global and local entry point. >> >> Setting a breakpoint on *$func effectively creates a breakpoint for >> the global >> entry point, so if the function is entered through the local entry >> point, the >> breakpoint doesn't trigger. >> >> Fix this by reverting commit cd919f5533c, and setting the breakpoint on >> ${func}_label instead. >> >> Tested on x86_64-linux and ppc64le-linux. >> --- >>   gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++---- >>   gdb/testsuite/lib/gdb.exp                      | 7 +------ >>   2 files changed, 5 insertions(+), 10 deletions(-) >> >> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >> index 08b5c645fa2..053f7229537 100644 >> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >> @@ -450,20 +450,20 @@ proc test { func compdir filename } { >>           error "not absolute" >>       } >> -    gdb_breakpoint *$func >> +    gdb_breakpoint ${func}_label >>       gdb_continue_to_breakpoint $func "$func \\(\\) at .*" >>       gdb_test_no_output "set filename-display absolute" >>       verbose -log "expect: ${absolute}" >> -    gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp >> ${absolute}]:999" "absolute" >> +    gdb_test "frame" " in $func \\(\\) at [string_to_regexp >> ${absolute}]:999" "absolute" >>       gdb_test_no_output "set filename-display basename" >>       verbose -log "expect: [file tail $filename]" >> -    gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp [file >> tail $filename]]:999" "basename" >> +    gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file >> tail $filename]]:999" "basename" >>       gdb_test_no_output "set filename-display relative" >>       verbose -log "expect: $filename" >> -    gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp >> $filename]:999" "relative" >> +    gdb_test "frame" " in $func \\(\\) at [string_to_regexp >> $filename]:999" "relative" >>       } >>   } >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index 17523f82996..2f1147159ad 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -787,14 +787,9 @@ proc gdb_continue_to_breakpoint {name >> {location_pattern .*}} { >>       global gdb_prompt >>       set full_name "continue to breakpoint: $name" >> -    set re_at_in " (at|in) " >> -    if { [regexp $re_at_in $location_pattern] } { >> -    set re_at_in " " >> -    } >> - >>       set kfail_pattern "Process record does not support instruction >> 0xfae64 at.*" >>       gdb_test_multiple "continue" $full_name { >> -    -re "(?:Breakpoint|Temporary breakpoint) >> .*$re_at_in$location_pattern\r\n$gdb_prompt $" { >> +    -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) >> $location_pattern\r\n$gdb_prompt $" { >>           pass $full_name >>       } >>       -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" { > > Looks like this makes the testsuite go from PASS to FAIL for aarch64. > Are we still stopping in the first instruction and ignoring prologues? No, we're stopping at the correct instruction, but whether the breakpoint is printed with or without instruction address is dependent on whether there is a prologue or not, which is an artefact of having a rudimentary line table. I've proposed a fix here ( https://sourceware.org/pipermail/gdb-patches/2022-September/191829.html ), which adds an extra entry in the line table, such that we'll always print without instruction address. Thanks, - Tom