From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 0601E3857736 for ; Mon, 15 May 2023 13:47:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0601E3857736 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6439e6f5a33so7874659b3a.2 for ; Mon, 15 May 2023 06:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1684158430; x=1686750430; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=/hPXxJVCdz+8x8nEuLZ8wl4q+2oYI6Cb/0r0q/G9BJs=; b=DQaM9tgKR+8bMhukYj12nH1TV+zboDYl1+LSMpHgWeheQ/VMqOiB2nHUVmbfFDQQP3 M132sOUiCF3K6911JUVCZIm4xFAbBUFOAAT8PckvflMXOUfG3SuXdzZrBHt91MOLGkMH 0KREweX+IdMWCfuR4XZrkcCM0v9/Tvy8S5VR9ncb211+AL75v8+ICEvgtN5cxlcElVy7 7W3gjxgEck04UhWYgSOuXaHETo6UyNEapLVHUciPxMrYEl46TxbvghjLjz56/SsJ5W/A rNlQZtb8qsqLVaQZ2O6N/q5R8GZ273CBj+TjvpIoj0cfV9wyp1miM/97xVcjFCe8AUmO uDZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684158430; x=1686750430; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/hPXxJVCdz+8x8nEuLZ8wl4q+2oYI6Cb/0r0q/G9BJs=; b=g63TOGde/DqVcNten1wzP3ZV5YNX4mZc7GtnqaZkNT6jhOZKtxk/xE/C+d3tyNi9YH xBbcsdidlJmU/AR2gDZ+UeXfl8MxoquD3K9EGOteeyheaVozuZ6dNHAVbt+7qgenWB1c 8219fxe2pgYW4LTz3TcTDQ4kliRkHxycY/MWSGaESQk9ULolJyqjBYgOZzZhcFL/WKrq Av9MKWV79A7QpPH52gWXSXJuiF1HxT94IamKraEwxUUnu0YP1MFKNdaNh/hmnvA+XGQz jnv3uhK41Ow4fJ+bQ+yIcNqBdYyHIMjsfElc6G82JI6yu0/y/fhR+0BIEd8BHf6QivYz oY+Q== X-Gm-Message-State: AC+VfDxDHmJ65OSN12h/ey0IblwODCu7p4sxpFbL5MpCFembd0tA17MP a1TRRN5/Xckv9H+iM5ULlgX1+A== X-Google-Smtp-Source: ACHHUZ51VrEJ8C9I63hiCS3TTIOkHxrE+QQsTwh1badrHiT2xeobt4QitLcWcvwtreqjj/G+A57E7A== X-Received: by 2002:a05:6a21:99a4:b0:104:e240:c365 with SMTP id ve36-20020a056a2199a400b00104e240c365mr10858113pzb.44.1684158429874; Mon, 15 May 2023 06:47:09 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id h23-20020a632117000000b00528da88275bsm11639739pgh.47.2023.05.15.06.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 06:47:09 -0700 (PDT) Date: Mon, 15 May 2023 06:47:09 -0700 (PDT) X-Google-Original-Date: Mon, 15 May 2023 06:47:04 PDT (-0700) Subject: Re: global pointer gets overwritten with dlopen(3) on RISC-V In-Reply-To: <87wn1dfurd.fsf@mid.deneb.enyo.de> CC: libc-alpha@sourceware.org, l.stelmach@samsung.com, schwab@suse.de, maskray@google.com, fweimer@redhat.com, adhemerval.zanella@linaro.org, joseph@codesourcery.com, binutils@sourceware.org, m.pikula@partner.samsung.com, m.szyprowski@samsung.com, k.lewandowsk@samsung.com From: Palmer Dabbelt To: fw@deneb.enyo.de Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Fri, 12 May 2023 08:13:10 PDT (-0700), fw@deneb.enyo.de wrote: > * Lukasz Stelmach via Libc-alpha: > >> We've got a program (the testee) written in C that we test with another >> one (a testing harness, the tester) written in C++ with gtest. So far, >> so good. To make the testing and inspection of the internal state of the >> testee easier the tester does not start the testee as a separate process >> but loads it with dlopen(3) and calls the testee's main() function. > > We specifically disallow this in current glibc because it does not > work in general—unless the application is really loadable as a shared > object (compiled as PIC and linked with -shared). Just popping back up here, as we got lost in the ABI discussions and were talking about it during the glibc patchwork call: essentially it boils down to us needing a more concrete reproducer for the bug. If GP is used in a shared object then we've got a bug somewhere, probably the linker. There's been some debate about what things like position independent mean in RISC-V land, so it's entirely possible there's something odd floating around here. If you can reproduce that it's probably a bug, but probably a LD/LLD bug. It sounds like there are no known bugs in glibc related to loading executables via dlopen(), as that doesn't work for any port due to a host of reasons (GP is just one of them). We might have some bug floating around, RISC-V specific or otherwise, though. If you have a reproducer for that then we can try and sort things out. Thanks!