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 9135F3947C3F for ; Tue, 7 Jun 2022 17:54:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9135F3947C3F Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 257HERTf016252; Tue, 7 Jun 2022 17:54:42 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gjaw98sau-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 17:54:41 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 257HGhks020428; Tue, 7 Jun 2022 17:54:41 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gjaw98sag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 17:54:41 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 257Hp12q004792; Tue, 7 Jun 2022 17:54:40 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma03dal.us.ibm.com with ESMTP id 3gfy1au9e8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 17:54:40 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp07027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 257HsdWp18678172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jun 2022 17:54:39 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A3CC06E052; Tue, 7 Jun 2022 17:54:39 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 17C8A6E050; Tue, 7 Jun 2022 17:54:39 +0000 (GMT) Received: from lexx (unknown [9.160.81.62]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 7 Jun 2022 17:54:38 +0000 (GMT) Message-ID: <6d82b4b8f30815f5dd98c001a8fe25632eb14a5a.camel@vnet.ibm.com> Subject: Re: [PATCH V4] PowerPC: fix for gdb.base/eh_return.exp From: will schmidt To: Carl Love , Pedro Alves , Kevin Buettner , gdb-patches@sourceware.org Date: Tue, 07 Jun 2022 12:54:38 -0500 In-Reply-To: <8ee42814763cc0e245c93f62c40cdaaad3ac65b2.camel@us.ibm.com> References: <76bea9ad010a71ea5e2c7fd78f818bdb399810a6.camel@us.ibm.com> <20220506110826.5e16c8b6@f35-zws-1> <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> <099c8f8d8729a0051f83a034d62c18f03c789167.camel@vnet.ibm.com> <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com> <998d3f4859f16b73afd5103b682246643fef6d42.camel@us.ibm.com> <8ee42814763cc0e245c93f62c40cdaaad3ac65b2.camel@us.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: WqoDFjsGdWPTz671WSD7kGriPDZO7qeF X-Proofpoint-ORIG-GUID: 95vY7MhOybiwwPYqmmN5wIwPHioZGakz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-07_07,2022-06-07_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206070072 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, 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, 07 Jun 2022 17:54:46 -0000 On Thu, 2022-06-02 at 10:00 -0700, Carl Love wrote: > Will, Pedro, Kevin, GDB maintainers: > Per the comments from Kevin, the patch was updated to check for the gcc > and xlc compilers on PowerPC. The patch was also tested and verified > on AIX which uses the gcc compiler to build gdb. The attempt to build > gdb using the xlc compiler fails due to unrelated compiler errors. The > xlc options to disable the Traceback Table was verified but that was > it. Ok. A few troublesome words in there, but the gist is that AIX uses GCC to build GDB, and the fix was verified using GCC. Any problems on AIX using XLC to build GDB are outside this scope. I believe I've seen a comment that the TBT is not included in the function size on AIX. I've not directly inspected, but it may actually be that AIX does not see the problem at all for that reason. > > I have updated the patch per the comments from Will. The new version > of the patch uses a PowerPC specific gcc option to suppress the > generation of the Traceback Table information. The Traceback > information for this function is contained in the .long statements > following the last instruction in the function. The Traceback table > consists of a series of bit fields. The assembler tries to interpret > the Traceback Table as instructions. If the bits in the Traceback > Table happen to match a known instruction, the assembler will print a > bogus instruction, otherwise the assembler just prints the bits using > the .long statement. Unfortunately, the disassembler does not know how > to locate the Traceback Table information at the end of a function. That could be reworked, but probably good enough. :-) > > With this patch, the existing gdb_test_multiple is able to locate the > last instruction in the function correctly. Previously, the break > point was set at the last .long statement which gdb will never reach. > The test now passes as gdb successfully executes to the identified last > instruction. Consider "With this patch, the traceback table is disabled, so the last instruction of the function is accurately found." > > Note, the use of the gcc mtraceback option is not valid on other > architectures. > > I have tested the patch on Linux Power 10 with gcc, AIX with the gcc > and Intel with gcc. > > Please let me know if this patch is acceptable. Thanks for the input > and help with the patch. > > Carl Love > > ------------------------------------------------------------------ > > PowerPC: fix for gdb.base/eh_return.exp > > Disable the Traceback Table generation on PowerPC for this test. The > Traceback Table consists of a series of bit fields to indicate things like > the Traceback Table version, language, and specific information about the > function. The Traceback Table is generated following the end of the code > for every function by default. The Traceback Table is defined in the > PowerPC ELF ABI and is intended to support debuggers and exception > handlers. The Traceback Table is displayed in the disassembly of functions > by default and is part of the function length. The table is tyupically > interpreted by the disassembler as data represented by .long xxx entries. s/tyup/typ/ > > Generation of the Traceback Table is disabled in this test using the > PowerPC specific gcc compiler option -mtraceback=no and the xlc option > additional_flags-qtable=none. Disabling the Traceback Table generation in And clang options "-mllvm -xcoff-traceback-table=false". > this test results in the gdb_test_multiple statement correctly locating the > address of the bclr instruction before the statement "End of assembler > dump." in the disassembly output. > --- > gdb/testsuite/gdb.base/eh_return.exp | 35 +++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp > index df55dbc72da..41d016486a1 100644 > --- a/gdb/testsuite/gdb.base/eh_return.exp > +++ b/gdb/testsuite/gdb.base/eh_return.exp > @@ -18,8 +18,41 @@ > > standard_testfile > > +# Set compiler flags. > +if {[istarget "powerpc*"]} then { > + # PowerPC generates a Traceback Table, as defined in the PPC64 ABI, > + # following each function by default. The Traceback Table information is > + # typically interpreted by the disassembler as data represented with > + # .long xxxx following the last instruction in the function. For example: > + # > + # Dump of assembler code for function eh2: > + # 0x00000000100009e0 <+0>: lis r2,4098 > + # ... > + # 0x0000000010000b04 <+292>: add r1,r1,r10 > + # 0x0000000010000b08 <+296>: blr > + # 0x0000000010000b0c <+300>: .long 0x0 > + # 0x0000000010000b10 <+304>: .long 0x1000000 > + # 0x0000000010000b14 <+308>: .long 0x1000180 > + # End of assembler dump. > + # > + # Disable the Traceback Table generation, using the PowerPC specific > + # compiler option, so the test gdb_test_multiple "disassemble eh2" will > + # locate the address of the blr instruction not the last .long statement. > + if { [test_compiler_info "gcc-*"] } { > + set compile_flags {debug nopie additional_flags=-mtraceback=no} > + } elseif { [test_compiler_info "xlc-*"] } { > + set compile_flags {debug nopie additional_flags=-qtbtable=none} > + } elseif { [test_compiler_info "clang-*"] } { > + set compile_flags {debug nopie additional_flags=-mllvm -xcoff-traceback-table=false} Does that work as-is? I wonder if the -xcoff-traceback option should have its own additional_flags= argument? > + } else { > + set compile_flags {debug nopie } > + } > +} else { > + set compile_flags {debug nopie} > +} > + > if {[prepare_for_testing "failed to prepare" $testfile $srcfile \ > - {debug nopie}]} { > + $compile_flags]} { ok Aside from the nits, this patch LGTM. Thanks, -Will > return -1 > } >