From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OPcTLYnOf2eDQAgAWB0awg (envelope-from ) for ; Thu, 09 Jan 2025 08:26:33 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=ieUed54D; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AB00D1E0C0; Thu, 9 Jan 2025 08:26:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1E9821E05C for ; Thu, 9 Jan 2025 08:26:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9FCE93858D33 for ; Thu, 9 Jan 2025 13:26:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FCE93858D33 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=ieUed54D Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 20CF53858D3C for ; Thu, 9 Jan 2025 13:25:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 20CF53858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 20CF53858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736429117; cv=none; b=ICsGvSk/QTb0s6ni0HIPcOj0uGQMdBNRHyPTtQdn6yzUVh/MoCwA5GzlmZwenHXlT7RHknLTpT87thsQXlcpi/M29WoukzDv5ahtXCtuxNB6YNoqPdA1mKx5MtokAA0OG7Fqlpahvx7eWse2hjVDXjhE51HQvIWaZZPNkFHzK90= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736429117; c=relaxed/simple; bh=FO5mJRlNuN3/UDESdqiIZnL7Js0zE81BQ4XnvoUP6fg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=LWCKz0CyJqibW8GU6aIZ195/2b52AoSWqrTjoNWX24p3HrG/PUM/R0PJzxU4Nq7HCdGjSik2989wiI9Sh2Lq5ziETAHoLjKR4Mn2+uB+W9DYKDK0AjPOVJzhRAbthJRfR3RuFqsAO8vVOS022jkWtDxReyimbHVxjfJFc8Baj3Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20CF53858D3C Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5093rG2H020240; Thu, 9 Jan 2025 13:25:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=cT8O629uo3IaAoI37c1ZFCZjR/Mr8Q 4n26jqan4NdmA=; b=ieUed54DzGZflpGhFmkoZvzO0fT6+2O2FsP6eVIv9K+oZq kM+CaKruxGCgwRumAk4wiwKjaZV3+0RkFtnMKTArvQYhfmxhbj94P31TXQ3S35IV +3M9wA5GbfqApbwfnkEq/2+zQjiXkMHHvAEoophf/PB4PqbC0Lv9Vv9gsWbDGN1f A9Y15YcftCmV5a05Jn7gr6PGWMI/jg02CTGuRuqX4eDUdWQEA6UxG4dBE4hWojr5 jTa3h0Re95nfIjhGySwcGjR9FmdtVzcq/0CzR1R7dzqK4c3QSdVuIeu6VntEmDI1 9fLqD8op4FDZJrp+cTHlJ8ukcDnni+CXUhQGqbgQ== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4426xqta67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2025 13:25:15 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 509DKVp2015809; Thu, 9 Jan 2025 13:25:14 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 43ygtm5624-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2025 13:25:14 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 509DPC0S33751610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Jan 2025 13:25:12 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A6462004B; Thu, 9 Jan 2025 13:25:12 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 850C320040; Thu, 9 Jan 2025 13:25:12 +0000 (GMT) Received: from li-07e5db4c-3052-11b2-a85c-815382633c95.ibm.com (unknown [9.152.222.94]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS; Thu, 9 Jan 2025 13:25:12 +0000 (GMT) From: Andreas Arnez To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 2/2] [gdb/tdep] Fix gdb.base/readnever.exp on s390x In-Reply-To: <20250109104406.30675-2-tdevries@suse.de> (Tom de Vries's message of "Thu, 9 Jan 2025 11:44:06 +0100") Organization: IBM Deutschland Research & Development GmbH References: <20250109104406.30675-1-tdevries@suse.de> <20250109104406.30675-2-tdevries@suse.de> Date: Thu, 09 Jan 2025 14:25:11 +0100 Message-ID: <874j28rufc.fsf@li-07e5db4c-3052-11b2-a85c-815382633c95.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 6TjuNqGbNhiIdYbXDAYX9sZi7ZOLFOeN X-Proofpoint-ORIG-GUID: 6TjuNqGbNhiIdYbXDAYX9sZi7ZOLFOeN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 suspectscore=0 phishscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 malwarescore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501090104 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Tom, On Thu, Jan 09 2025, Tom de Vries wrote: > On s390x-linux, I run into: > ... > (gdb) backtrace > #0 0x000000000100061a in fun_three () > #1 0x000000000100067a in fun_two () > #2 0x000003fffdfa9470 in ?? () > Backtrace stopped: frame did not save the PC > (gdb) FAIL: gdb.base/readnever.exp: backtrace > ... > > This is really due to a problem handling the fun_three frame. When generating > a backtrace from fun_two, everying looks ok: > ... > $ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \ > -ex "b fun_two" \ > -ex run \ > -ex bt > ... > #0 0x0000000001000650 in fun_two () > #1 0x00000000010006b6 in fun_one () > #2 0x00000000010006ee in main () > ... > > For reference the frame info with debug info (without -readnever) looks like this: > ... > $ gdb -q -batch outputs/gdb.base/readnever/readnever \ > -ex "b fun_three" \ > -ex run \ > -ex "info frame" > ... > Stack level 0, frame at 0x3fffffff140: > pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a > called by frame at 0x3fffffff1f0 > source language c. > Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c > Locals at 0x3fffffff140, Previous frame's sp in v0 > ... > > But with -readnever, like this instead: > ... > Stack level 0, frame at 0x0: > pc = 0x100061a in fun_three; saved pc = 0x100067a > called by frame at 0x3fffffff140 > Arglist at 0xffffffffffffffff, args: > Locals at 0xffffffffffffffff, Previous frame's sp in r15 > ... > > An obvious difference is the "Previous frame's sp in" v0 vs. r15. > > Looking at the code: > ... > 0000000001000608 : > 1000608: b3 c1 00 2b ldgr %f2,%r11 > 100060c: b3 c1 00 0f ldgr %f0,%r15 > 1000610: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) > 1000616: b9 04 00 bf lgr %r11,%r15 > ... > it becomes clear what is going on. This is an unusual prologue. > > Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack, > instead they're saved into call-clobbered floating point registers. > > [ For reference, this is the prologue of fun_two: > ... > 0000000001000640 : > 1000640: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) > 1000646: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) > 100064c: b9 04 00 bf lgr %r11,%r15 > ... > where the first instruction stores registers r11 to r15 to stack. ] > > Gdb fails to properly analyze the prologue, which causes the problems getting > the frame info. > > Fix this by: > - adding handling of the ldgr insn [1] in s390_analyze_prologue, and > - recognizing the insn as saving a register in > s390_prologue_frame_unwind_cache. > > This gets us instead: > ... > Stack level 0, frame at 0x0: > pc = 0x100061a in fun_three; saved pc = 0x100067a > called by frame at 0x3fffffff1f0 > Arglist at 0xffffffffffffffff, args: > Locals at 0xffffffffffffffff, Previous frame's sp in f0 > ... > and: > ... > (gdb) backtrace^M > #0 0x000000000100061a in fun_three ()^M > #1 0x000000000100067a in fun_two ()^M > #2 0x00000000010006b6 in fun_one ()^M > #3 0x00000000010006ee in main ()^M > (gdb) PASS: gdb.base/readnever.exp: backtrace > ... > > Tested on s390x-linux. > > PR tdep/32417 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417 > > [1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf > --- > gdb/s390-tdep.c | 39 +++++++++++++++++++++++++++++++++++++++ > gdb/s390-tdep.h | 1 + > 2 files changed, 40 insertions(+) > > diff --git a/gdb/s390-tdep.c b/gdb/s390-tdep.c > index 70affc914c2..36a70d8642c 100644 > --- a/gdb/s390-tdep.c > +++ b/gdb/s390-tdep.c > @@ -855,6 +855,11 @@ s390_analyze_prologue (struct gdbarch *gdbarch, > || is_rre (insn64, op_lgr, &r1, &r2)) > data->gpr[r1] = data->gpr[r2]; > > + /* LDGR r1, r2 --- load from register to floating-point register > + (64-bit version). */ > + else if (is_rre (insn64, op_ldgr, &r1, &r2)) > + data->fpr[r1] = data->gpr[r2]; > + > /* L r1, d2(x2, b2) --- load. */ > /* LY r1, d2(x2, b2) --- load (long-displacement version). */ > /* LG r1, d2(x2, b2) --- load (64-bit version). */ > @@ -2542,6 +2547,40 @@ s390_prologue_frame_unwind_cache (const frame_info_ptr &this_frame, > && data.fpr_slot[i] != 0) > info->saved_regs[S390_F0_REGNUM + i].set_addr (cfa - data.fpr_slot[i]); > > + /* Handle this type of prologue: > + ldgr %f2,%r11 > + ldgr %f0,%r15 > + where call-clobbered floating point registers are used as register save > + slots. */ > + for (i = 0; i < S390_NUM_FPRS; i++) > + { > + int fpr = S390_F0_REGNUM + i; > + > + /* Check that fpr is a call-clobbered register. */ > + if (s390_register_call_saved (gdbarch, fpr)) > + continue; > + > + /* Check that fpr contains the value of a register at function > + entry. */ > + if (data.fpr[i].kind != pvk_register) > + continue; > + > + int entry_val_reg = data.fpr[i].reg; > + > + /* Check that entry_val_reg is a call-saved register. */ > + if (!s390_register_call_saved (gdbarch, entry_val_reg)) > + continue; > + > + /* In the prologue, we've copied: > + - the value of a call-saved register (entry_val_reg) at function > + entry, to > + - a call-clobbered floating point register (fpr). > + > + Heuristic: assume that makes the floating point register a register > + save slot, leaving the value constant throughout the function. */ > + info->saved_regs[entry_val_reg].set_realreg (fpr); > + } > + > /* Function return will set PC to %r14. */ > info->saved_regs[S390_PSWA_REGNUM] = info->saved_regs[S390_RETADDR_REGNUM]; > > diff --git a/gdb/s390-tdep.h b/gdb/s390-tdep.h > index bfcb8f17c56..d8f5fd5e185 100644 > --- a/gdb/s390-tdep.h > +++ b/gdb/s390-tdep.h > @@ -82,6 +82,7 @@ enum > op1_lgfi = 0xc0, op2_lgfi = 0x01, > op_lr = 0x18, > op_lgr = 0xb904, > + op_ldgr = 0xb3c1, > op_l = 0x58, > op1_ly = 0xe3, op2_ly = 0x58, > op1_lg = 0xe3, op2_lg = 0x04, Thanks! This is OK. Approved-By: Andreas Arnez -- Andreas