From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id C0D7A38346B4 for ; Thu, 21 Apr 2022 18:21:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0D7A38346B4 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 23LFi18s004860; Thu, 21 Apr 2022 18:21:41 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3fjer8wx7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Apr 2022 18:21:41 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 23LIIxUh012698; Thu, 21 Apr 2022 18:21:40 GMT Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0b-001b2d01.pphosted.com with ESMTP id 3fjer8wx7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Apr 2022 18:21:40 +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 23LIHGGk013101; Thu, 21 Apr 2022 18:21:40 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma02wdc.us.ibm.com with ESMTP id 3fg2xwa4qh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Apr 2022 18:21:40 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 23LILdb325624936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Apr 2022 18:21:39 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 618B9AE063; Thu, 21 Apr 2022 18:21:39 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A1B2AE064; Thu, 21 Apr 2022 18:21:38 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.11.46]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 21 Apr 2022 18:21:38 +0000 (GMT) Message-ID: <8c9d6b7cae96fd49cb455e6b1913b20ee8347c67.camel@us.ibm.com> Subject: Re: [PATCH] Fix for gdb.base/solib-search.exp test. From: Carl Love To: Simon Marchi , dje@google.com, gdb-patches@sourceware.org Cc: Rogerio Alves , Will Schmidt , cel@us.ibm.com Date: Thu, 21 Apr 2022 11:21:37 -0700 In-Reply-To: <8f0ddc69-6cbd-14f6-8bb9-a3d3fb963493@simark.ca> References: <8fe6f3bee129c0a3159d3ef57c942b9473255d8d.camel@us.ibm.com> <8f0ddc69-6cbd-14f6-8bb9-a3d3fb963493@simark.ca> 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: 0Vhzx0lA5lbIsj7VPaNdrrUhvOa-N3Rn X-Proofpoint-ORIG-GUID: m-aE_R-BfM0ulvGgPIg4r18ILvrewffl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-21_03,2022-04-21_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 mlxscore=0 priorityscore=1501 phishscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204210096 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, 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-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, 21 Apr 2022 18:21:44 -0000 Simon: The test needs the lib2 addresses to be different in the right and wrong cases. That is the point of introducing function lib2_spacer with the ifdef RIGHT compiler directive. On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the dynamic linker to move the addresses of the library. You can also get the same effect on PowerPC but you must use a value much larger than 8192. The key thing is that the test was not properly setting RIGHT to defined to get the lib2_spacer function on Intel and Powerpc. Without the patch, we have the Intel backtrace for the bad libraries: backtrace #0 break_here () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7fae156 in ?? () #2 0x00007fffffffc150 in ?? () #3 0x00007ffff7fbb156 in ?? () #4 0x00007fffffffc160 in ?? () #5 0x00007ffff7fae146 in ?? () #6 0x00007fffffffc170 in ?? () #7 0x00007ffff7fbb146 in ?? () #8 0x00007fffffffc180 in ?? () #9 0x0000555555555156 in main () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection) The backtrace on Intel with the good libraries is: backtrace #0 break_here () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7fae156 in lib2_func4 () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49 #2 0x00007ffff7fbb156 in lib1_func3 () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib1.c:49 #3 0x00007ffff7fae146 in lib2_func2 () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:30 #4 0x00007ffff7fbb146 in lib1_func1 () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib1.c:30 #5 0x0000555555555156 in main () at /home/carll/GDB/binutils-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) PASS: gdb.base/solib-search.exp: backtrace (with right libs) You can see in the one case the backtrace is correct and the other it is wrong on Intel. This is due to the fact that the ARRAY_SIZE caused the dynamic linker to move the library function addresses around. I believe it has to do with the default size of the data and code sections used by the dynamic linker. So without the patch the backtrace on PowerPC looks like: backtrace #0 break_here () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7f007f4 in lib2_func4 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib2.c:49 #2 0x00007ffff7f307f4 in lib1_func3 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib1.c:49 #3 0x00007ffff7f007ac in lib2_func2 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib2.c:30 #4 0x00007ffff7f307ac in lib1_func1 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib1.c:30 #5 0x000000001000074c in main () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search.c:23 for both the good and bad libraries. The patch fixes defining RIGHT in solib-search-lib1.c and solib-search- lib2.c. Note, without the patch the lib1_spacer and lib2_spacer functions do not show up in the object dump of the Intel or Powerpc libraries as it should. The patch fixes that by making sure RIGHT gets defined. Now with the patch the backtrace for the bad library on PowerPC looks like: backtrace #0 break_here () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7f0083c in __glink_PLTresolve () from /home/carll/GDB/build-play/gdb/testsuite/outputs/gdb.base/solib-search/solib-search-lib2.so Backtrace stopped: frame did not save the PC And the backtrace for the good libraries on PowerPC looks like: backtrace #0 break_here () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7f0083c in lib2_func4 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib2.c:49 #2 0x00007ffff7f3083c in lib1_func3 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib1.c:49 #3 0x00007ffff7f007cc in lib2_func2 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib2.c:30 #4 0x00007ffff7f307cc in lib1_func1 () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search-lib1.c:30 #5 0x000000001000074c in main () at /home/carll/GDB/build-play/gdb/testsuite/../../../binutils-gdb-play/gdb/testsuite/gdb.base/solib-search.c:23 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) PASS: gdb.base/solib-search.exp: backtrace (with right libs) The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not sufficient to cause the dymanic linker to allocate the libraries at different addresses. I don't claim to understand the specifics of how the dynamic linker works and what the default size is for the data and code sections are. My guess is by default PowerPC allocates a larger data size by default, which is large enough to hold array[8192]. The default size of the data section allocated by the dynamic linker on Intel is not large enough to hold array[8192] thus causing the code section on Intel to have to move when the large array is defined. Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause the library addresses to occur at different addresses as the larger data section forces the code section to a different address. That was actually my original fix for the program until I spoke with Doug Evans who originally wrote the test. Doug noticed that RIGHT was not getting defined as he originally intended in the test. With the patch to fix the definition of RIGHT, PowerPC has a bad and a good backtrace because the address of lib1_func3 and lib2_func4 both move because lib1_spacer and lib2_spacer are now defined before lib1_func3 and lib2_func4. I don't claim to understand the details of how the dynamic linker works to layout the data and code sections on Intel versus PowerPC. But, clearly you can change the address of lib1_func3 and lib2_func4 by defining or not defining RIGHT and thus mess up the backtrace. The bottom line is without the patch, the lib1_spacer and lib2_spacer function doesn't show up in the binary for the correct or incorrect library on Intel or PowerPC. With the patch, RIGHT gets defined as originally intended for the test on both architectures and lib1_spacer and lib2_spacer function show up in the binaries on both architectures changing the other function addresses as intended thus causing the test work as intended on PowerPC. Carl Love On Thu, 2022-04-21 at 09:39 -0400, Simon Marchi wrote: > On 2022-03-22 17:49, Carl Love via Gdb-patches wrote: > > GDB maintainers: > > > > The following patch fixes the setting of the variable > > right_lib_flags > > in the solib-search.exp test. With the fix the test now run > > correctly > > on Powerpc. > > > > The patch has been tested on a Power 10 system. > > > > Please let me know if the patch is acceptable for mainline gdb. > > Thanks. > > > > Carl Love > > > > --------------------------------------------------- > > Fix for gdb.base/solib-search.exp test. > > > > The variable right_lib_flags is not being set correctly to define > > RIGHT. > > The value RIGHT is needed to force the address of the library > > functions > > lib1_func3 and lib2_func4 to occur at different address in the > > wrong and > > right libraries. > > > > With RIGHT defined correctly, functions lib1_func3 and lib2_func4 > > occur > > at different addresses the test runs correctly on Powerpc. > > --- > > gdb/testsuite/gdb.base/solib-search.exp | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/gdb/testsuite/gdb.base/solib-search.exp > > b/gdb/testsuite/gdb.base/solib-search.exp > > index eaabe508bf0..202e79d85de 100644 > > --- a/gdb/testsuite/gdb.base/solib-search.exp > > +++ b/gdb/testsuite/gdb.base/solib-search.exp > > @@ -54,7 +54,7 @@ set binfile2_lib [standard_output_file > > ${libname2}.so] > > > > set lib_flags [list debug ldflags=-Wl,-Bsymbolic] > > set wrong_lib_flags "$lib_flags additional_flags=-DARRAY_SIZE=1" > > -set right_lib_flags "$lib_flags additional_flags=-DARRAY_SIZE=8192 > > -DRIGHT" > > +set right_lib_flags "$lib_flags additional_flags=-DARRAY_SIZE=8192 > > additional_flags=-DRIGHT" > > Hi Carl, > > Intuitively, this looks good. But I'd like to understand why this > fails > on PPC but not x86-64. Can you show the failure that you see? It's > also a good idea to put it in the commit log for future > reference. You > can paste the FAIL line that you get before the patch, and the PASS > line > that you get after the patch. Include the relevant lines from > gdb.log > just before those, so we can see what changed between before and > after. > > Simon