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 21353385843A for ; Thu, 1 Sep 2022 14:16:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21353385843A 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 57EC420110; Thu, 1 Sep 2022 14:16:10 +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 31EBD13A79; Thu, 1 Sep 2022 14:16:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id G4jlCqq+EGOmVwAAMHmgww (envelope-from ); Thu, 01 Sep 2022 14:16:10 +0000 Message-ID: <42d8db2c-4cf9-b37e-0ec1-39f4fe1302ef@suse.de> Date: Thu, 1 Sep 2022 16:16:09 +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][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp Content-Language: en-US To: Carl Love , Luis Machado , gdb-patches@sourceware.org, Ulrich Weigand References: <20220811115809.GA19509@delia> <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> From: Tom de Vries In-Reply-To: <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, 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: Thu, 01 Sep 2022 14:16:17 -0000 On 8/15/22 18:54, Carl Love via Gdb-patches wrote: > Tom: > > OK, I took a look at how the test used to work and how it is now > working and I see what the issue is. > > PowerPC has two entry points, local and global. The test used to set > the breakpoint for the function at the local entry point. With your > changes, the breakpoint is now being set at the global breakpoint which > is before the local breakpoint. The function is actually entered at > the local breakpoint thus gdb never "sees" the breakpoint that was set. > Specfically, here is the objdump for the test: > > 00000000100006e0 : > 100006e0: 02 10 40 3c lis r2,4098 <- Global entry point > 100006e4: 00 7f 42 38 addi r2,r2,32512 > 100006e8: f8 ff e1 fb std r31,-8(r1) > 100006ec: d1 ff 21 f8 stdu r1,-48(r1) > 100006f0: 78 0b 3f 7c mr r31,r1 > 100006f4: 00 00 00 60 nop <- Local entry point > 100006f8: 28 81 22 39 addi r9,r2,-32472 > 100006fc: 00 00 29 81 lwz r9,0(r9) > 10000700: 01 00 49 39 addi r10,r9,1 > 10000704: 00 00 00 60 nop > 10000708: 28 81 22 39 addi r9,r2,-32472 > 1000070c: 00 00 49 91 stw r10,0(r9) > 10000710: 30 00 3f 38 addi r1,r31,48 > 10000714: f8 ff e1 eb ld r31,-8(r1) > 10000718: 20 00 80 4e blr > > When I look at the output before the patch, we see: > > Breakpoint 2, 0x00000000100006f4 in compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-name.c:999 > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename > set filename-display absolute > > > Note the breakpoint 2 address is 0x00000000100006f4 which is on the > NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of the > code when the function is called via the global entry point. So > previously, the breakpoint was set at local entry point. > > With the patch, we now see: > > Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999. > (gdb) continue > > Continuing. > [Inferior 1 (process 2520351) exited normally] > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename (the program exited) > > Now we note that the breakpoint 2 is set at 0x100006e0 which is the > global entry point. > > It looks to me that we need to make sure we set the breakpoint at the > local address. > > Off hand, I am not sure how to get your changes to "proc > gdb_continue_to_breakpoint" to select the local entry point not the > global entry point. Perhaps Ulrich has some ideas??? > Hi Carl, thanks for reporting this, and the analysis. I've submitted a patch to fix this here ( https://sourceware.org/pipermail/gdb-patches/2022-September/191647.html ). Thanks, - Tom > Carl Love > > > On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote: > >> >> Looks like the patch was applied last Friday. We are now seeing 129 >> test failures related to this commit on PowerPC. The failures are >> seen >> on Power 8, 9 and 10. >> >> Here is an initial bit of the failures: >> >> ... >> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999. >> (gdb) continue >> Continuing. >> [Inferior 1 (process 2520351) exited normally] >> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: continue to breakpoint: >> compdir_missing__ldir_missing__file_basename (the program exited) >> set filename-display absolute >> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: set filename-display >> absolute >> expect: /home/carll/GDB/build- >> current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir- >> file-name.d/rdir/tmp-dw2-dir-file-name.c >> frame >> No stack. >> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: absolute >> set filename-display basename >> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: set filename-display >> basename >> expect: tmp-dw2-dir-file-name.c >> frame >> No stack. >> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: basename >> set filename-display relative >> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: set filename-display >> relative >> expect: tmp-dw2-dir-file-name.c >> frame >> No stack. >> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_basename: relative >> set directories >> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: >> compdir_missing__ldir_missing__file_relative: set directories >> break *compdir_missing__ldir_missing__file_relative >> Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line >> 999. >> (gdb) continue >> The program is not being run. >> >> etc. >> >> === gdb Summary === >> >> # of expected passes 129 >> # of unexpected failures 128 >> >> I have not had time yet to try and dig into the failures to figure >> out >> the cause. I will take a look at the failures to see what is going >> on. >> >> Anyway, just wanted to let you know what I am seeing on PowerPC. >> >> Carl >> >> On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches >> wrote: >>> On 8/11/22 12:58, Tom de Vries wrote: >>>> Hi, >>>> >>>> When running test-case gdb.dwarf2/dw2-dir-file-name.exp on >>>> x86_64- >>>> linux, we >>>> have: >>>> ... >>>> (gdb) break compdir_missing__ldir_missing__file_basename^M >>>> Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line >>>> 999.^M >>>> (gdb) continue^M >>>> Continuing.^M >>>> ^M >>>> Breakpoint 2, 0x00000000004004c4 in \ >>>> compdir_missing__ldir_missing__file_basename () \ >>>> at tmp-dw2-dir-file-name.c:999^M >>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ >>>> compdir_missing__ldir_missing__file_basename: continue to >>>> breakpoint: \ >>>> compdir_missing__ldir_missing__file_basename >>>> ... >>>> >>>> When trying to set a breakpoint on >>>> compdir_missing__ldir_missing__file_basename, the architecture- >>>> specific >>>> prologue skipper starts at 0x4004c0 and skips past two insns, to >>>> 0x4004c4: >>>> ... >>>> 00000000004004c0 : >>>> 4004c0: 55 push %rbp >>>> 4004c1: 48 89 e5 mov %rsp,%rbp >>>> 4004c4: 8b 05 72 1b 20 >>>> 00 mov 0x201b72(%rip),%eax # 60203c >>>> 4004ca: 83 c0 01 add $0x1,%eax >>>> 4004cd: 89 05 69 1b 20 >>>> 00 mov %eax,0x201b69(%rip) # 60203c >>>> 4004d3: 90 nop >>>> 4004d4: 5d pop %rbp >>>> 4004d5: c3 ret >>>> ... >>>> >>>> And because the line table info is rudamentary: >>>> ... >>>> CU: tmp-dw2-dir-file-name.c: >>>> File name Line number Starting >>>> address View Stmt >>>> tmp-dw2-dir-file- >>>> name.c 999 0x4004c0 x >>>> tmp-dw2-dir-file- >>>> name.c 1000 0x4004d6 x >>>> tmp-dw2-dir-file-name.c - 0x4004d6 >>>> ... >>>> the address does not fall at an actual line, so the breakpoint is >>>> shown with >>>> address, both when setting it and hitting it. >>>> >>>> when running the test-case with aarch64-linux, we have similarly: >>>> ... >>>> (gdb) break compdir_missing__ldir_missing__file_basename^M >>>> Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line >>>> 999.^M >>>> ... >>>> due to the architecture-specific prologue skipper starting at >>>> 0x400610 and >>>> skipping past two insns, to 0x400618: >>>> ... >>>> 0000000000400610 : >>>> 400610: 90000100 adrp x0, 420000 < >>>> __libc_start_main@GLIBC_2.17> >>>> 400614: 9100b000 add x0, x0, #0x2c >>>> 400618: b9400000 ldr w0, [x0] >>>> 40061c: 11000401 add w1, w0, #0x1 >>>> 400620: 90000100 adrp x0, 420000 < >>>> __libc_start_main@GLIBC_2.17> >>>> 400624: 9100b000 add x0, x0, #0x2c >>>> 400628: b9000001 str w1, [x0] >>>> 40062c: d503201f nop >>>> 400630: d65f03c0 ret >>>> ... >>>> >>>> But interestingly, the aarch64 architecture-specific prologue >>>> skipper is >>>> wrong. There is no prologue, and the breakpoint should be set at >>>> 0x400610. >>>> >>>> By using "break *compdir_missing__ldir_missing__file_basename" >>>> we can get the breakpoint set at 0x400610: >>>> ... >>>> (gdb) break *compdir_missing__ldir_missing__file_basename^M >>>> Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line >>>> 999.^M >>>> ... >>>> and make the test-case independent of prologue analysis. >>>> >>>> This requires us to update the expected patterns. >>>> >>>> The fix ensures that once the aarch64 architecture-specific >>>> prologue skipper >>>> will be fixed, this test-case won't start failing. >>>> >>>> Tested on x86_64-linux. >>>> >>>> Any comments? >>>> >>>> Thanks, >>>> - Tom >>>> >>>> [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp >>>> >>>> --- >>>> gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++---- >>>> gdb/testsuite/lib/gdb.exp | 7 ++++++- >>>> 2 files changed, 10 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>> index 4d3f767f597..4c4c1ff07af 100644 >>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp >>>> @@ -396,20 +396,20 @@ proc test { func compdir filename } { >>>> error "not absolute" >>>> } >>>> >>>> - gdb_breakpoint $func >>>> + gdb_breakpoint *$func >>>> gdb_continue_to_breakpoint $func "$func \\(\\) at .*" >>>> >>>> gdb_test_no_output "set filename-display absolute" >>>> verbose -log "expect: ${absolute}" >>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp >>>> ${absolute}]:999" "absolute" >>>> + gdb_test "frame" "#0 $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" " in $func \\(\\) at [string_to_regexp [file >>>> tail $filename]]:999" "basename" >>>> + gdb_test "frame" "#0 $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" " in $func \\(\\) at [string_to_regexp >>>> $filename]:999" "relative" >>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp >>>> $filename]:999" "relative" >>>> } >>>> } >>>> >>>> diff --git a/gdb/testsuite/lib/gdb.exp >>>> b/gdb/testsuite/lib/gdb.exp >>>> index a8f25b5f0dd..70fc019eeb9 100644 >>>> --- a/gdb/testsuite/lib/gdb.exp >>>> +++ b/gdb/testsuite/lib/gdb.exp >>>> @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name >>>> {location_pattern .*}} { >>>> global gdb_prompt >>>> set full_name "continue to breakpoint: $name" >>>> >>>> + set re_at_in " (at|in) " <-NEED TO FIX TO ALWAYS GIVE local entry point for POWERPC ?? >>>> + 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) .* (at|in) >>>> $location_pattern\r\n$gdb_prompt $" { >>>> + -re "(?:Breakpoint|Temporary breakpoint) >>>> .*$re_at_in$location_pattern\r\n$gdb_prompt $" { >>>> pass $full_name >>>> } >>>> -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" >>>> { >