From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 85C823847718 for ; Wed, 3 Apr 2024 11:18:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 85C823847718 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 85C823847718 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712143129; cv=none; b=RmgkCgiNTbyvPEMmouKTxpLHqE8m75Hdkiegk4IW13NinDoDvD81H5gia1rkAL7S9Ton7b0Bcq65w584j1hD4FsUQi2aP98vuhcgnfEfvTDjjOpX19HigTgN2tro9sUVGhbTkEFazs+fTePUBzXpwKtYhqgMi3ytwCCYlnC86pQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712143129; c=relaxed/simple; bh=fOZq8gxHqPdRDmjgGluZiy+lpRPSOi/9dTrRJ+XwfMc=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=fvwtnTNN8WaZPLN/GfrEor0STPavwhWpYsmfZ8KVdW90PwVvQUN0TvHnW2LF82A/2Z7bh2UNUMXTf7E7rnWEKEOvFlY712M7SQOcirMflDhYGFciXBMx9wUXOqQ0X1K6YtH3IGFlRGbccf15oO1SsJkJiO58Wuf2vTd85JoyrT0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712143128; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=T8T953ptSoJk2irRB4TDrGTQGe8EUpxR7SaiCb9i40k=; b=e2FdXb13aVDAt8cth9cDvuP2PwUfFuazJsTxLXov7QvtUR7n3YpCvSXfXFpsRl5hOtGsMu QWNyOK8uXKGlW39m4xJQcetzDiut+VQymR0YYuJCITHG8IPPQzatzlef85RQtjSlKXPxiv 50Ao222bGdSlbP8YJRFELDTPhMaea7s= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-692-cjenLqedO--o1yWCx3-49A-1; Wed, 03 Apr 2024 07:18:45 -0400 X-MC-Unique: cjenLqedO--o1yWCx3-49A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A9C4380598D; Wed, 3 Apr 2024 11:18:44 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 355081C060CE; Wed, 3 Apr 2024 11:18:44 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 433BIcUx1850085 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Apr 2024 13:18:38 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 433BIaFU1850084; Wed, 3 Apr 2024 13:18:36 +0200 Date: Wed, 3 Apr 2024 13:18:36 +0200 From: Jakub Jelinek To: "Kewen.Lin" Cc: Ajit Agarwal , Peter Bergner , Segher Boessenkool , David Edelsohn , Michael Meissner , gcc-patches Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Message-ID: Reply-To: Jakub Jelinek 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> MIME-Version: 1.0 In-Reply-To: <0844fb39-4ff5-3eca-8c70-11d2c2fdeca1@linux.ibm.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 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. > 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. 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. Jakub