From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 4296C221BE for ; Wed, 3 Apr 2024 04:31:24 +0200 (CEST) Received: (qmail 27989 invoked by uid 550); 3 Apr 2024 02:31:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27954 invoked from network); 3 Apr 2024 02:31:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712111469; x=1712716269; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ryW5VDZ08lZgF0qt0HAdm/uLJPbLSB+xI17s/YJgexM=; b=lW+w3Icql2nzBs0WRjqo3Fy9R7uZFQ5bahNRt91SU4tiA5c7zHYiY2yRb7ZrnSAX+2 YIAcAuwbZxKep25FbqbIqVoPCwcZ7NOGQhDsEmM+i/346UmJwd6ik8ut5A3atdzHwHER 2VsxlZCaA/TTHXu6pP2Mtt8bZkTaEgZF/S7sDHLRr1Aps4bHUgf2RSM4D0tMcZOCtEj+ LpbfdwlXDQs1jCByK9EeDB3twyyUu0DxZzBzowtb9EOA+GCMuV6A1ePH9ayvGjwOUZO6 uW+9NDTjL3Nm1Y0f5rlKn/JJZCBdfuFBYGGTXa4mbeYFuq6YH+J/u4XqN84RHi+msrCu dMNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712111469; x=1712716269; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ryW5VDZ08lZgF0qt0HAdm/uLJPbLSB+xI17s/YJgexM=; b=sIYSbkSKqh5Sd3HMXL20zXUS5b3mHZMprP5gRVRJKpDbWu+xdszXM8/BBCQ/8KpHbo lPszFjj0WoAha5WirVs2hKovPL1gU8t94t16Rx5MY1f+aa5cDI6hbTcr4AAFTj1P4gW4 E/wyAx4z8qVjDiKJJxTbGvnGtUYMtxe5FHRU46biYvA9F3yH8+fcTazBFvGACN/0kLO3 x8V1yRQ5ODajHtFw02wb6k2EH2ai92ujxo2CkyUVA7lzwH0ALiInOPgytERGWAjPTF07 kWVcpy+g+xltWu4zuh7030H5NGiQVtEJ6rzlWPZwHMsoSWsjPonWoeU+SnIJatDORDQ2 BMBg== X-Gm-Message-State: AOJu0Yx7bKNMOkdnuGqLPg+JW7tUbtmw60aKbYCYws/9dVPBTqalTMAM mjORA7mXSmr1LP7HbvyhxgThCHixbdWneycJou+E8bmkfAKP3ho2HVQKOCWMb/W/h3JqMV2qzeY sGGB6AKPpQHedZScCqRDWqUEgN5o= X-Google-Smtp-Source: AGHT+IHGY63IttdW5GwPAklKl+aZMX4q0Pwbfg5hBdxAloVPLf8wrAhyCg7a0uB5R3A477h9KhKMJSomPKafgQ36wug= X-Received: by 2002:a17:90a:3047:b0:299:3035:aede with SMTP id q7-20020a17090a304700b002993035aedemr1288295pjl.44.1712111469119; Tue, 02 Apr 2024 19:31:09 -0700 (PDT) MIME-Version: 1.0 References: <20240328200319.4016902-1-jcmvbkbc@gmail.com> <20240328230116.GM4163@brightrain.aerifal.cx> <20240329014824.GG32430@brightrain.aerifal.cx> In-Reply-To: <20240329014824.GG32430@brightrain.aerifal.cx> From: Max Filippov Date: Tue, 2 Apr 2024 19:30:57 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [RFC v2 0/2] xtensa FDPIC port On Thu, Mar 28, 2024 at 6:48=E2=80=AFPM Rich Felker wrote= : > On Thu, Mar 28, 2024 at 05:48:50PM -0700, Max Filippov wrote: > > On Thu, Mar 28, 2024 at 4:00=E2=80=AFPM Rich Felker w= rote: > > > On Thu, Mar 28, 2024 at 01:03:17PM -0700, Max Filippov wrote: > > > > functional/dlopen fails with the > > > > src/functional/dlopen.c:39: dlsym main failed: (null) > > > > There's no failure in the dlsym call, but the pointers don't match. > > > > > > Is this something related to canonical function descriptors? Is it > > > musl's fault or a bug in the tooling? I suspect the latter. > > > > Yes, dlsym() returns the pointer into def.dso->funcdescs, > > but (void *)main returns the pointer to the canonical function > > descriptor. I understand that the linker must use the > > R_XTENSA_FUNCDESC relocation for the locally defined > > global symbol instead of the .rofixup entries. > > If the xtensa FDPIC ABI is going to be that the linker makes canonical > function descriptors, I think that's workable, but the dynamic linker > would need a way to find and usee them. I'm not sure how that would > work. > > The simple (but probably less efficient) way is to copy what SH did > and have the dynamic linker always be responsible for them (load > descriptor address from GOT). I've built and tested SH FDPIC toolchain, it fails this test in exactly the same way: pointer loaded directly does not match the pointer returned by dlsym(). --=20 Thanks. -- Max