From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id BF005385802D for ; Thu, 11 Jan 2024 09:06:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF005385802D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BF005385802D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::32c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704964004; cv=none; b=sk+TDfJF+1oZrdm3C+HnzmGxKBSiKslyYGxQ8gGIZjdrLODdQDP+coOoRtM4TeI3w1g3blCkGPQAYNTXXz8GUQ7DJ6IcJ3biFcZwyH445j4Q/zTTRb6UbMdgif+XMT58KWsGryvWrlxmNXZlKYtozH+Qj64ufCbPRRVv2i/RRN0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704964004; c=relaxed/simple; bh=T/k7sPyOapnQea9GnwB6EZutc5WyGHBwWWiCCwiNonY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HGEiMeqY8q9rCcwzF5JUMVtpLIkpNQCGZYEtShOT8JExHBkyknVCMtrnUE/ovJlpiySIEnmIeG2z3d7sJE5BgZuDQ0obwA1rGB9ZxG7Ie7Izfd8/3FZFlI0W+ctuwmJJtergSUFdP6idNx/ZEbEub0otjFrwhEv6p/04hdXwCJ8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-6ddf26eba3cso926748a34.0 for ; Thu, 11 Jan 2024 01:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1704964002; x=1705568802; darn=gcc.gnu.org; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=847U4mcLQJo+JNP4uusOPBtE/LsvXIaFwUYSTfLN3Bc=; b=KdUNjkRMtdrWztwZGwEnnwTcRuMQrS9azQFqZb85RhLVtuTLBByI9vre0tOHzn1ll4 K21y3luqaTJ/XJXzWoXwfb7Iiz6SiM0lCIAgmYowcFdVPEekoaDy6D+0JrpD7fAhQKAi FseNA5313FjxMMGEf7MqlkrcuF6yd97ngfpDO0QB/h1AuySKMPoFtYE/xhrH3rPuskwI 87j37nM2oX6jFNnQHmywadXKBntbxvf/IlaXu2zPPaN5sPkLDYGjpJ0zgaERBkY5u0f5 xobojm4PS61FluZetrXg4FGQ3yGRyQDOIOeVqc4bOZz5JxD5/3AlY3NYWfx8k7ZiOGHg AlsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704964002; x=1705568802; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=847U4mcLQJo+JNP4uusOPBtE/LsvXIaFwUYSTfLN3Bc=; b=crH4XzLotAGrdFkqQFk8tYXdJC7RmWNmYf/ryY0aACLxQAXHHwkwyPyjqFYL/J3BKj OpzLnzyttbHVZ20F8j1/v29+LH/0tllNXcRh3rZsSY/TcMLjJY1y3j6lnagkieBIe6A+ PDi3sa1SO8snIBIwEEF8+kwG2OHkg5aDinDtqhBSyKgFdp50nXHZUplV914Qtu3yEN1C mT/qprqLky02WT3VlL839HZPufU6hLDhsCWF2bnoh1lmaZNBTATzU0eNuHhM6YfNDGwd EU4mamzwNvgvjanwR/60LWHUxKoKfkXOB85DDAzmaWgAn4C4X/SLSew1KYMS0kvIkP0I 6AIQ== X-Gm-Message-State: AOJu0Yx11mMwqQ6re/y1yTREMoAUSKTf8ujeNSc4WNdnichA1KJu4v9+ PJMDAhToxZZZYy2ASOTAotctOjQKu/KR X-Google-Smtp-Source: AGHT+IF5yyRa7WOCCffRYnHT1gpyfvesj1eggbXjozksDovsXFB3lY+6FNvXmvfVfoxgEAkT6kJxSw== X-Received: by 2002:a9d:7a85:0:b0:6dd:ef0b:4f62 with SMTP id l5-20020a9d7a85000000b006ddef0b4f62mr1021894otn.77.1704964002041; Thu, 11 Jan 2024 01:06:42 -0800 (PST) Received: from free.home ([187.106.42.20]) by smtp.gmail.com with ESMTPSA id e11-20020a63d94b000000b005c200b11b77sm702433pgj.86.2024.01.11.01.06.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 01:06:41 -0800 (PST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 40B95Rqj182935 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 06:05:28 -0300 From: Alexandre Oliva To: "Kewen.Lin" Cc: GCC Patches , Richard Biener , Jakub Jelinek , Peter Bergner , Segher Boessenkool , Jeff Law , Richard Sandiford Subject: Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100] Organization: Free thinker, does not speak for AdaCore References: <91d2c107-0168-791b-b5fa-de21c2345f84@linux.ibm.com> Date: Thu, 11 Jan 2024 06:05:27 -0300 In-Reply-To: <91d2c107-0168-791b-b5fa-de21c2345f84@linux.ibm.com> (Kewen Lin's message of "Mon, 8 Jan 2024 10:35:07 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING autolearn=no 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 Jan 7, 2024, "Kewen.Lin" wrote: > As PR113100 shows, the unbiasing introduced by r14-6737 can > cause the scrubbing to overrun and screw some critical data > on stack like saved toc base consequently cause segfault on > Power. Ugh. Sorry about the breakage, and thanks for addressing it during my absence. Happy GNU Year! :-) > By checking PR112917, IMHO we should keep this unbiasing > guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 && > TARGET_STACK_BIAS), similar to some existing code special > treating SPARC stack bias. I'm afraid this change will most certainly regress 32-bit sparc, because of the large register save area. I had been hesitant to introduce yet another target configuration knob, but it looks like this is what we're going to have to do to accommodate all targets. > I also expect the culprit commit can > affect those ports with nonzero STACK_POINTER_OFFSET. IMHO it really shouldn't. STACK_POINTER_OFFSET should be the "Offset from the stack pointer register to the first location at which outgoing arguments are placed", which suggests to me that no data that the callee couldn't change should go in the area below (or above) %sp+S_P_O. ISTM that PPC sets up a save area between the outgoing args and the stack pointer; I don't think that's very common, but I suppose other targets that do so would also define STACK_POINTER_OFFSET to nonzero so as to reserve those bits. But whether they should be cleared by stack scrubbing, as on sparc, or preserved, as on ppc, depends on the ABI conventions, so we probably can't help yet another knob :-/ I'll take care of that, and update the corresponding documentation. Thanks, -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive