From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5l/AOj7d+2LDFCgAWB0awg (envelope-from ) for ; Tue, 16 Aug 2022 14:09:02 -0400 Received: by simark.ca (Postfix, from userid 112) id DD5751E5EA; Tue, 16 Aug 2022 14:09:02 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=U5cb6gRC; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A3AF81E222 for ; Tue, 16 Aug 2022 14:09:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 20A513858436 for ; Tue, 16 Aug 2022 16:01:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20A513858436 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1660665688; bh=aJsWtrIZZKi559MTDkC9wafbcFoNqjSYyQnzTZDp6Qs=; h=Subject:To:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=U5cb6gRCxsyGaT7TCotftju44fYV64sL2Di5vQGCXa0XHSWu3CpX1o9MxwTGYa0GA IZPNzNkFsEJlLutXO1E+rKYyyQRNNNLTYnqF9M183gdglxPu9uCpg3UkWCNSUFmQYh qk0iihFBX2nIYidjSJaJho5f1Dg9WzY3p3AZJtBM= Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 97A393858430 for ; Tue, 16 Aug 2022 16:01:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97A393858430 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27GFfvEg022171; Tue, 16 Aug 2022 16:00:57 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j0e3sgmg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Aug 2022 16:00:57 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27GFoeA9015847; Tue, 16 Aug 2022 16:00:56 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma04dal.us.ibm.com with ESMTP id 3hx3k9ymvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Aug 2022 16:00:56 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27GG0tvY63766804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Aug 2022 16:00:55 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1294078063; Tue, 16 Aug 2022 16:00:55 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5645F78068; Tue, 16 Aug 2022 16:00:54 +0000 (GMT) Received: from lexx (unknown [9.160.66.1]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 16 Aug 2022 16:00:54 +0000 (GMT) Message-ID: <9fddf4d36f06f9156d8aed059a765676712917dd.camel@vnet.ibm.com> Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp To: Luis Machado , Carl Love , Tom de Vries , gdb-patches@sourceware.org, Ulrich Weigand Date: Tue, 16 Aug 2022 11:00:53 -0500 In-Reply-To: References: <20220811115809.GA19509@delia> <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> <10b3195562b41db8f77d3c0cbd984d0da270190e.camel@vnet.ibm.com> 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-GUID: SKYegEJAwmirQymMAhDhpDLwIZKdyMqt X-Proofpoint-ORIG-GUID: SKYegEJAwmirQymMAhDhpDLwIZKdyMqt 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-16_08,2022-08-16_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 phishscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 clxscore=1015 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208160059 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: , From: will schmidt via Gdb-patches Reply-To: will schmidt Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Tue, 2022-08-16 at 08:43 +0100, Luis Machado wrote: > On 8/15/22 20:12, will schmidt wrote: > > On Mon, 2022-08-15 at 09:54 -0700, Carl Love 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??? > > > > From a glance that the patch that updated dw2-dir-file-name.exp; > > ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 ) > > the change there was effectively > > > > - gdb_breakpoint $func > > + gdb_breakpoint *$func > > > > with assorted regexp changes to match. > > > > The patch description goes into detail, but I interpret the gist of it > > as avoiding the aarch64 architecture prologue skipper, since that > > prologue skipper does something wrong, with entanglements in the line > > table info. > > Though the aarch64 prologue skipper is indeed mistaken here, Tom's patch only > makes the test less reliant on whatever prologue skippers do and instead just > got for a breakpoint straight at the entry point. I don't have the code up in front of me, I'll punt to Carl to point out where things are, if necessary.. :-) For PowerPC, as described in the ELFv2 ABI, that entry point is the global entry point (GEP). We also have (and use as much as possible) a local entry point (LEP). Code to update the TOC pointer (R2) exists between the two entry points, so when a local function calls this function, the TOC set-up is skipped. This was a significant part of the new ABI. And though I was hung up on the GEP/LEP gunk, I recognize the prologue skipping code also skips therest of the, um, prologue. It is perfectly fine to set a breakpoint between the two entry points, or anywhere within the prologue, we just can't expect it to hit anything between the entry points unless we are called via the global entry point. So for instance ... Dump of assembler code for function parse_size: 0x000000000000091c <+0>: addis r2,r12,2 << GEP,*parse_size 0x0000000000000920 <+4>: addi r2,r2,30180 0x0000000000000924 <+8>: mflr r0 << LEP 0x0000000000000928 <+12>: std r0,16(r1) 0x000000000000092c <+16>: std r31,-8(r1) 0x0000000000000930 <+20>: stdu r1,-144(r1) 0x0000000000000934 <+24>: mr r31,r1 0x0000000000000938 <+28>: std r3,104(r31) << End of Prologue. 0x000000000000093c <+32>: li r9,1 << start (gdb) break parse_size Breakpoint 1 at 0x93c: file get_page_size.c, line 11. (gdb) break *parse_size Breakpoint 2 at 0x91c: file get_page_size.c, line 9. (gdb) break * 0x000000000000091c Note: breakpoint 2 also set at pc 0x91c. Breakpoint 3 at 0x91c: file get_page_size.c, line 9. Thanks, -Will > > It is a void function with void return type, so no much going on. Maybe it needs > to be adapted somewhat to the PowerPC case? > > > > The powerpc prologue skipper (wherever it is) was presumably handling > > the local/global entry points properly. Since the test now species a > > specific address (*$func), the prologue skipper is no longer involved. > > How does powerpc handle a breakpoint at a particular address? > > > The patch should probably be reverted, but I defer to others if I've > > misunderstood part of this issue.. > > > > Thanks > > -Will > > > > > > > > > > > > > > > > > > > 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 $" > > > > > > {