From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id E46903858D20 for ; Wed, 6 Dec 2023 22:12:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E46903858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 E46903858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701900767; cv=none; b=xkRTdiWmyIX0XGGOd6E2fRS1dJqH8/N0gOhAvSabTWBgheyNnq0MxTFxFd2TQfExTWZxi4gcCd37lHmh8h81MQ3HUY4THq2QGrdxes9Vz119hrW3eg3P9IUdjTDuKWHMc8jqQrAhxs+pnA5aLMnaE+B5cOSt77U8ztICv53685k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701900767; c=relaxed/simple; bh=iYtmZ6mGg48UT7pFnbko21T9BVbkerU6fKvLPCnx6to=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=tP5qpBlKqc7fNeJIth4srvit7oxAgmlZnJRqXX/+h9N1Lbg0sUSfiDXHjT5E2myz/ExvCUSBiBTtgGmetjubGnUzLFvEDcAb3URrPgKj9I3A7hnZf3J4d7WJrAMfaqIY1L2R+asWK06UbfuZClEqMxbW5mf8z1FQk38wCXonpcM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6ce939ecfc2so9038b3a.2 for ; Wed, 06 Dec 2023 14:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1701900764; x=1702505564; 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=Qbch4MehlHaYmtTilV+dcSHkK+Dow73ZMsG0JUxUMmQ=; b=lnn7Yee+aXrVaZvZ4sw8CMw7SlmuVxdYHaAYN5k/rYYfIjcxXYlRdzVcE3gSzJjphK B2gpTr9fKRkiInTPWRyP6SN3wVNtZB/OLB6hH8SkgqpO50PNH08erW6Uuln0EEa/CoSu aB7xRqj2d9+Y3jynxqK+6Ww9lGrpe6jtFbmHQG9+TZPKyar+b3sfc4a196XvJk5v8YWU FtJ//xUXXI3Q7bn3tkUkWdvZraICZnqi6HFXiG5Hp9FycqTlNDyRYKlXlQOviFPKTKE6 xrG7NX+tfZvlF7ZBlNLOkVjI5yYD+UBRtbXDAg9fO+idooMlCxAApbtBbPD31sVNWW1q HrXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701900764; x=1702505564; 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=Qbch4MehlHaYmtTilV+dcSHkK+Dow73ZMsG0JUxUMmQ=; b=nV39YCVITDEGMUM/5kuyiHCXWcNFoEY2wcGE9HopO5o1WqvCN5n9GZLA+3HVDMgeNa PrerfNrQD8YRg5TyqgBRUBeP4AbdSOGOTtjEYBoFiWRGyuFDh0YZ534Z2fVreN8g+eAF +ltiDeKZ8MpZ2kBb2PmphkqXjXQ2g5GMiXlaUEMGPXtek3mqCxVT/PEVQPOT99daQRkG B/IFgX1tP0wlKbbCk7Ay+m4F8RSELAhDJoexqP4f5+ccrhTD5WAf6h7VEjueuI7rmGe/ KGT3xbjDzciVTeg+6d9oL0AmYKLQ9MoSvXZDCnHP6W+G1uep7T25nHoa2XSgcwmAiqxK Yzaw== X-Gm-Message-State: AOJu0YwVB6H1g9wbXFTrJ1YKGJ6KaYxr35Tf5/c0lg5hkEFLa2SbGez7 r2Gz0DGz4FwXgBogfZNt4+NwRg== X-Google-Smtp-Source: AGHT+IFP2CYQnDED57lUKyUHKfIccrg4ie4oD5aVPFdvOxX863IRrnEhE7vdjWGWPz98tfH+1YVjyw== X-Received: by 2002:a05:6a20:442a:b0:18c:b133:dea4 with SMTP id ce42-20020a056a20442a00b0018cb133dea4mr1657569pzb.42.1701900763934; Wed, 06 Dec 2023 14:12:43 -0800 (PST) Received: from free.home ([2804:14c:4d1:44a5::1000]) by smtp.gmail.com with ESMTPSA id n19-20020aa78a53000000b006ce7d0d2590sm18681pfa.0.2023.12.06.14.12.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Dec 2023 14:12:43 -0800 (PST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 3B6MCPnu257812 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 6 Dec 2023 19:12:25 -0300 From: Alexandre Oliva To: Thomas Schwinge Cc: Tobias Burnus , Richard Biener , , Jeremy Bennett , Craig Blackmore , Graham Markall , Martin Jambor , "Jan Hubicka" , Jim Wilson , Jeff Law , Jakub Jelinek , Tom de Vries Subject: Re: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing Organization: Free thinker, does not speak for AdaCore References: <87lea7sh0h.fsf@euler.schwinge.homeip.net> Date: Wed, 06 Dec 2023 19:12:25 -0300 In-Reply-To: <87lea7sh0h.fsf@euler.schwinge.homeip.net> (Thomas Schwinge's message of "Wed, 6 Dec 2023 12:32:46 +0100") 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=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING 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 Dec 6, 2023, Thomas Schwinge wrote: > As I understand things, this cannot be implemented (at the call site) for > nvptx, given that the callee's stack is not visible there: PTX is unusual > in that the concept of a "standard" stack isn't exposed. Not even when one PTX function calls another? Interesting. I'd hoped that with control over entering and leaving strub contexts, one could (manually) ensure they'd run in the same execution domain. But if not even that is possible, it will render the current strub implementation entirely unusable for this target indeed. Now, it doesn't seem to me that the build errors being experienced have to do with that, but rather with lack of or incomplete support for __builtin_{frame,stack}_address(). Are those errors expected when using these builtins on this target? I'd have expected them to compile, even if something went wrong at runtime. > Instead of allowing "strub" pieces that can be implemented, should this > whole machinery generally be disabled (forced '-fstrub=disable', or via a > new target hook?)? The libgcc functions should then not get defined > (thus, linker error upon accidental use), or should just '__builtin_trap' > if that makes more sense? Need an effective-target for the test cases. > Alternatively, we may also leave the generic middle end handling alive, > and 'sorry' (or similar) in the nvptx back end, as necessary? Disabling the runtime bits is easy, once we determine what condition we wish to test for. I suppose testing for target support in the compiler, issuing a 'sorry' in case the feature is required, would provide something for libgcc configure and testsuite effective-target to test for and decide whether to enable runtime support and run the tests. -- 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