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 430813858C74 for ; Wed, 9 Mar 2022 20:52:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 430813858C74 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 229KA9Gd005520; Wed, 9 Mar 2022 20:52:24 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3eny19ce1w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Mar 2022 20:52:24 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 229KT0ur017080; Wed, 9 Mar 2022 20:52:23 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com with ESMTP id 3eny19ce1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Mar 2022 20:52:23 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 229KgMC6010455; Wed, 9 Mar 2022 20:52:21 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma03wdc.us.ibm.com with ESMTP id 3epwg628fj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Mar 2022 20:52:21 +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 229KqLsI21823800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Mar 2022 20:52:21 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69C24B206B; Wed, 9 Mar 2022 20:52:21 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 79869B2064; Wed, 9 Mar 2022 20:52:20 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.79.233]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 9 Mar 2022 20:52:20 +0000 (GMT) Message-ID: <4feed1aaa0d5d9b166c7c0e608918f883137fad1.camel@us.ibm.com> From: Carl Love To: Bruno Larsen , gdb-patches@sourceware.org, cel@us.ibm.com Cc: Rogerio Alves , luis.machado@arm.com Date: Wed, 09 Mar 2022 12:52:19 -0800 In-Reply-To: <3b2ab293-92d9-aa9b-bff2-3b6eaff27d59@redhat.com> References: <442684e3f81aa1df073960bd45918106acefa2b9.camel@us.ibm.com> <0fbaf3783401f8aa8e76a4d3928efff46485ab8d.camel@us.ibm.com> <3b2ab293-92d9-aa9b-bff2-3b6eaff27d59@redhat.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: ZioRrMSnetQxHNz3yHZDXi76FBPCsmT8 X-Proofpoint-ORIG-GUID: 0o6vXQmwjXS80dGED2JR1XOwyWbHsYw8 Subject: RE: [PATCH] Updated, fix reverse stepping multiple contiguous PC ranges X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-09_09,2022-03-09_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 spamscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 malwarescore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203090106 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: Wed, 09 Mar 2022 20:52:30 -0000 Bruno: On Wed, 2022-03-09 at 09:23 -0300, Bruno Larsen wrote: > > > Thanks for looking at this. Since I don't test on aarch64 often, > > > I am > > > not sure if I see regressions or racy testcases, but it does fix > > > the > > > issue you mentioned, and there doesn't seem to be regressions on > > > x86_64 hardware. I have a few nits, but the main feedback is: > > > could > > > you add a testcase for this, using the dwarf assembler and > > > manually creating contiguous PC ranges, so we can confirm that > > > this is not > > > regressed in the future on any hardware? > > > > > > Also, I can't approve a patch, but with the testcase this patch > > > is > > > mostly ok by me > > > > > > > I have not writen anything in dwarf assembler in the past. Off the > > top > > of my head, don't know how to create such a test case. It does > > seem > > that there are the two testcases gdb.reverse/solib-precsave.exp > > and > > gdb.reverse/solib-reverse.exp which the patch fixes. I guess the > > dwarf > > assembly test would be similar to the C level code. > > > > Do you have an example of how to write dwarf assembly or a pointer > > to a > > tutorial on writting dwarf? > > I have recently worked on gdb.base/until-trailing-insns.exp, that > uses the dwarf assembler quite a bit to create a line table. I am not > sure how one would go about making contiguous ranges, but maybe you > can find something in gdb/testsuite/lib/dwarf.exp to help you. I have studied until-trailing-insns.exp, dwarf.exp and the DWARF Debugging Informat Format Version 5 document. I really don't see how to write the test case you desire. The issue is gdb is supposed to step in reverse one statement at a time. The two testcases that the patch fix have two statements on the same line. Specifically from gdb.reverse/solib-reverse.c it has the source code line: b[0] = 6; b[1] = 9;. It is this line where the reverse step fails to stop in between the two statements. I tried dumping the DWARF info for a very simple program with two statements on the same line as in the two test cases that fail to see what GCC generates. The test program is: int main() { int i,j; i = 1; j=3; printf("i=%d, j=%d\n", i, j); } gcc -g -O0 test2.c -o test2 objdump -g -W -S -d test2 > test2.dump The interesting dump information is: int main() { 7fc: 02 00 4c 3c addis r2,r12,2 800: 04 77 42 38 addi r2,r2,30468 804: a6 02 08 7c mflr r0 808: 10 00 01 f8 std r0,16(r1) 80c: f8 ff e1 fb std r31,-8(r1) 810: 81 ff 21 f8 stdu r1,-128(r1) 814: 78 0b 3f 7c mr r31,r1 int i,j; i = 1; j=3; 818: 01 00 20 39 li r9,1 // Store i = 1 81c: 68 00 3f 91 stw r9,104(r31) 820: 03 00 20 39 li r9,3 // Store j = 3 824: 6c 00 3f 91 stw r9,108(r31) printf("i=%d, j=%d\n", i, j); Line Number Statements: [0x00000040] Set column to 12 [0x00000042] Extended opcode 2: set Address to 0x7fc [0x0000004d] Special opcode 10: advance Address by 0 to 0x7fc and Line by 5 to 6 [0x0000004e] Set column to 5 [0x00000050] Special opcode 105: advance Address by 28 to 0x818 and Line by 2 to 8 [0x00000051] Set column to 11 [0x00000053] Special opcode 33: advance Address by 8 to 0x820 and Line by 0 to 8 [0x00000054] Set column to 3 [0x00000056] Special opcode 34: advance Address by 8 to 0x828 and Line by 1 to 9 [0x00000057] Set column to 1 [0x00000059] Special opcode 146: advance Address by 40 to 0x850 and Line by 1 to 10 [0x0000005a] Advance PC by 36 to 0x874 [0x0000005c] Extended opcode 1: End of Sequence Here I can see that "[0x00000053] Special opcode 33: advance Address by 8 to 0x820 and Line by 0 to 8" refers to address 0x820 in the binary which is the assembly statement for j=3. Also, it says advance Line by 0, i.e. it is the same line number as the previous statement i=1. The line entries in the line table, i.e. Line Number, are different. In your message, you said to create a test case that has "continuous PC ranges." I don't see where/how that would be reflected in the DWARF info as dumped above? I don't see GCC generating information/code with continuous PC ranges. I have not found anything that would enable me to do that. Each assembly statement has a unique PC value, but the DWARF info does track the source Line number separately. Clearly GCC is generating DWARF that specifies the statements are in the same line but with different PC values. I have not found anything that would help me "making contiguous ranges" that you refere to. I really don't see how a new DWARF test is going to be different or better then the existing C tests? Perhaps you could explain more as to the value of this new test and why the existing two C code tests which the patch fixes are not sufficient to detect a future gdb regression? Sorry, I just don't see how to create the test you propose and at this point, and I am not seeing the value in it. I don't claim to be an expert on DWARF so it is entirely possible I am missing something here. Thanks for your feedback and help on this. Carl