From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id A3AF73858D1E for ; Mon, 15 Aug 2022 16:02:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A3AF73858D1E Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27FFt4Cg019129; Mon, 15 Aug 2022 16:02:32 GMT Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hyqh9bn33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Aug 2022 16:02:31 +0000 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27FFZm15003712; Mon, 15 Aug 2022 16:02:31 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma02wdc.us.ibm.com with ESMTP id 3hx3k9mttg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Aug 2022 16:02:31 +0000 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27FG2ULq13107834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Aug 2022 16:02:30 GMT Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6CA946A047; Mon, 15 Aug 2022 16:02:30 +0000 (GMT) Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 06C0F6A04F; Mon, 15 Aug 2022 16:02:29 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.56.41]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 15 Aug 2022 16:02:29 +0000 (GMT) Message-ID: <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp From: Carl Love To: Luis Machado , Tom de Vries , gdb-patches@sourceware.org Date: Mon, 15 Aug 2022 09:01:57 -0700 In-Reply-To: References: <20220811115809.GA19509@delia> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: X3snDDt3km0lc2dJpk88dRUg_D2_8a5y X-Proofpoint-GUID: X3snDDt3km0lc2dJpk88dRUg_D2_8a5y X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-15_08,2022-08-15_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 mlxlogscore=797 phishscore=0 malwarescore=0 suspectscore=0 bulkscore=0 adultscore=0 impostorscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208150062 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: Mon, 15 Aug 2022 16:02:39 -0000 Tom: 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) " > > + 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 $" { >