From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id ED127385800A for ; Mon, 19 Jul 2021 22:22:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED127385800A Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16JM40Ss045634; Mon, 19 Jul 2021 18:22:33 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 39wh6dses4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 18:22:33 -0400 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 16JMIRIm010075; Mon, 19 Jul 2021 22:22:32 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma04dal.us.ibm.com with ESMTP id 39upubdgm0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 22:22:32 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 16JMMVJG25493918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jul 2021 22:22:31 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A0FE9B2066; Mon, 19 Jul 2021 22:22:31 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 41118B205F; Mon, 19 Jul 2021 22:22:31 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.3.57]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 19 Jul 2021 22:22:31 +0000 (GMT) Message-ID: From: Carl Love To: Andrew Burgess Cc: gdb@sourceware.org Date: Mon, 19 Jul 2021 15:22:30 -0700 In-Reply-To: <20210719164804.GC1688065@embecosm.com> References: <20210719164804.GC1688065@embecosm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-14.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 8f-GvqV6chvjCJWNkrlbWdC41vOeZoI- X-Proofpoint-GUID: 8f-GvqV6chvjCJWNkrlbWdC41vOeZoI- Subject: RE: Question: gdb.tui/tui-layout-asm.exp X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-19_11:2021-07-19, 2021-07-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 impostorscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107190127 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 22:22:36 -0000 Andrew, gdb developers: >.... I think > that for some reason this check is failing: > > if {[Term::wait_for $re_line] \ > && [regexp $re_line [Term::get_line 1]]} { > > If this was not failing, and you kept scrolling far enough, then a > blank like would appear. Yes, that test does appear to be failing. I have added some debug statements to the gdb.tui/tui-layout-asm.exp test as follows: set line1 [Term::get_line 1] puts " " puts "Carll line1 $line1" puts "Carll re_line $re_line" if {([Term::wait_for $re_line] \ && [regexp $re_line [Term::get_line 1]])} { puts "Carll true" # We scrolled successfully. } else { puts "Carll false" fail "$testname (scroll failed)" Term::dump_screen break } The interesting output is: Carll line1 | 0x100007a4 <__glink_PLTresolve+44> ld r11,8(r11) | Carll re_line \|\s+0x100007a8\s+<__glink_PLTresolve\+48>\s+bctr\s+\| CARLL, timeout, return 1 Carll true Carll line1 | 0x100007a8 <__glink_PLTresolve+48> bctr | Carll re_line \|\s+0x100007ac\s+<__libc_start_main@plt>\s+b\s+0x10000778\s+<__glink_PLTres\| <--should match CARLL, timeout, return 1 Carll true Carll line1 | 0x100007ac <__libc_start_main@plt> b 0x10000778 <__glink_PLTres| <-- this line but the test fails Carll re_line \|\s+0x100007b0\s+<__gmon_start__@plt>\s+b\s+0x10000778\s+<__glink_PLTres\| CARLL, timeout, return 1 Carll false FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll failed) So the if statement is checking to see if line1 matches the re_line above it. The match statement is [regexp $re_line [Term::get_line 1]] The final test fails for some reason? Note this is the first test were a line had an @ symbol in it. The value of re_line which is set re_line [string_to_regexp $line] looks like the generated regular expression of the line should match the next $line1 string. I am not aware of the @ having any special meaning in a regular expression that would confuse the regexp command? Maybe someone else can spot why the two lines don't seem to match? They look OK to me. Carl