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 6BC723847718 for ; Wed, 3 Apr 2024 12:18:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BC723847718 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 6BC723847718 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=1712146740; cv=none; b=M1EtRrbmolTxgcCIZVwjaXTcpJNfFNMtykfN5wm8VK4oiOB3T3HEGtIIG9mEEvcXzucZ4RkBG0mYohedVJJCEENl33H8i3GQkh+JNNjSIWT+eDLmmOV/+NWr4dwW8UXUFNiRXyZZktHZbeqHUgmgM1dGqy3TetwWangBimFKrJw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712146740; c=relaxed/simple; bh=mJ+kwZPEVAxwFT4hKCdwYSoPublFIkJHIpB4IZu3rpk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JK9MPWexTdmSff7uQ2TTFVVrsSRmnpdQLCtSvQYpWmlFEkDnEKL9XQYUKTM4axTjtnNvTxEFvmBh9Vrz1NqB94z2CjZooiXLyp35ABIWWJB4WnSez+nJvMaQD7Yg3WqCxANiwPlsHIHwwRORu+r0qHkODjTPZ2EYVu/OnrQajF0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 433BUphg014134; Wed, 3 Apr 2024 12:18:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=2GCwJKMXZXRJsVAXsFkVbzmwtYqJ/F+ofCKoeREOSy0=; b=nvNIZX1WCT1Czy0SUopJCBsWCc0gmyEC78doiiAm2rh7dJACnmLUXB65sXE72+x7WaXO Kpnjy9plCN5/2YhLk6xVz+RJqnOKeO3tpxgQ/r+JwLwJDGYfEX8goLrLxXlJ8iUlXEPJ fxtuKM5A5S9fy/q3KxXA/DJLIrZwNa49rBB8fb+OWdKG1woTougKy7b/L8jyexshmGXU A4jOkdpVbeHbADGnc/x1gwqJuwIfoofMlZZVDK+SgqR6xWfgp8gIT3S/SKrFZqL62HBq Opx1eAFAk/re32LzyinRHk3NAzO/e7YWwCCZeiL0TLFeI7Meyw+9ToX7KgwVQlBTyo/c 7g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x95y3r4m5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 12:18:54 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 433CIss2032454; Wed, 3 Apr 2024 12:18:54 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x95y3r4m2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 12:18:54 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 433Ailqd008425; Wed, 3 Apr 2024 12:18:53 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3x6w2u5f1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 12:18:53 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 433CIlja52363572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2024 12:18:49 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AFBBC2004B; Wed, 3 Apr 2024 12:18:47 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5C3520040; Wed, 3 Apr 2024 12:18:44 +0000 (GMT) Received: from [9.197.227.64] (unknown [9.197.227.64]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 3 Apr 2024 12:18:44 +0000 (GMT) Message-ID: <044ac22f-a662-6686-dba8-785d50b723dc@linux.ibm.com> Date: Wed, 3 Apr 2024 20:18:43 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Content-Language: en-US To: Jakub Jelinek Cc: Ajit Agarwal , Peter Bergner , Segher Boessenkool , David Edelsohn , Michael Meissner , gcc-patches References: <76307976-77b0-48f0-90b9-6dcec02e3c8f@linux.ibm.com> <6a592b9f-d536-4a0e-aa00-ee8d4a778afc@linux.ibm.com> <5a2e511a-3a29-4cdd-88b1-12a6274d5a79@linux.ibm.com> <5293fc93-5899-8863-e776-e2a75b0d97a4@linux.ibm.com> <0844fb39-4ff5-3eca-8c70-11d2c2fdeca1@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: JW500sPlZYBuGH-Q6iBC3u9erkPmn8CR X-Proofpoint-GUID: OOZqAM02BjHm6ebJGt1jgo0Yx9qsUd3J X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-03_10,2024-04-03_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 adultscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 bulkscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2404030085 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: on 2024/4/3 19:18, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote: >> Thanks for the details on debugging support, but IIUC with this workaround >> being adopted, the debuggability on hidden args are already broken, aren't? > > No. > In the correct program case, which should be the usual case, the caller will > pass the arguments and one should be able to see the values in the debugger > even if the function doesn't actually use those arguments. > If the caller is buggy and doesn't pass those arguments, one should be able > to see garbage values for those arguments and perhaps that way figure out > that the program is buggy and fix it. But it's not true with Ajit's current implementation that is lying args are passed in r11..., so whatever the caller is usual (in argument save area) or not (not such value), the values are all broken. > >> Since with a usual caller, the actual argument is passed in argument save >> area, but the callee debug information says the location is %r11 or some >> other stack slot. >> >> I think the difficulty is that: with this workaround, for some arguments we >> are lying they are not passed in argument save area, then we have to pretend >> they are passed in r11,r12..., but in fact these registers are not valid to >> pass arguments, so it's unreasonable and confusing. With your explanation, >> I agree that stripping DECL_ARGUMENTS chains isn't a good way to eliminate >> this confusion, maybe always using GP_ARG_MIN_REG/GP_ARG_MAX_REG for things >> exceeding GP_ARG_MAX_REG can reduce the unreasonableness (but still confusing >> IMHO). > > If those arguments aren't passed in r11/r12, but in memory, the workaround > shouldn't pretend they are passed somewhere where they aren't actually > passed. Unfortunately the current implementation doesn't conform this, I misunderstood you knew that. > Instead, it should load them from the memory where they are actually > normally passed. > What needs to be ensured though is that those arguments are for -O0 loaded > from those stack slots and saved to different stack slots (inside of the > callee frame, rather than in caller's frame), for -O1+ just not loaded at > all and pretended to just live in the caller's frame, and most importantly > ensure that the callee doesn't try to think there is a parameter save area > in the caller's frame which it can use for random saving related or > unrelated data. So, e.g. REG_EQUAL/REG_EQUIV shouldn't be used, nor tell > that the 1st-8th arguments could be saved to the parameter save area. > So, for the 1st-8th arguments it really should act as if there is no > parameter save area and for the DECL_HIDDEN_STRING_LENGTH ones after it > as it those are passed in memory, but as if that memory is owned by the > caller, not callee, so it is not correct to modify that memory. Now I got your points. I like this proposal and also believe it makes more sense on both the resulted assembly and the debuggability support, though it sounds the implementation has to be more complicated than what's done. Thanks for all the inputs!! BR, Kewen