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 B8C4121BB6 for ; Thu, 4 Apr 2024 10:56:47 +0200 (CEST) Received: (qmail 1338 invoked by uid 550); 4 Apr 2024 08:56:43 -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 1299 invoked from network); 4 Apr 2024 08:56:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712220993; x=1712825793; 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=0g43qswG+atL/G0fxnkoPOWaAVW1GFWFQe0FTZITK7g=; b=iu84cy2mK1gz7peYtNyjjE1rRNJ0CZ/km+Dopn0YS6QDH2nqSBvo/VQQ6fVFyYj7Xq WBd3OV4M4cTk+P6JGNJvrkJjhfpWty53DmxmVZFu0O+5q64zYYu9oinb6ElmgP5iV0SG 37mahXEu/Ya1oO4BJQg9NeTjIB2nrnKA1O+xxvSLRHcavycIj8CMJjfQ+1W+UDuayV6M MMKMCeKiH2K2LDODSb6EhFmPIMpetv5oJ1gLJf1MAq8gjPG6PP11JwZp70tD+dB3DDSa 28JmGc6/JyfTtxKQsVB3gqRtbdhl623LfOiFfKIGI1r+GFQYJ+C6vdaEVTPBGI/Eg7KP wJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712220993; x=1712825793; 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=0g43qswG+atL/G0fxnkoPOWaAVW1GFWFQe0FTZITK7g=; b=OydRzTUxlpX4tVfo/R45YzbHRfKcBApz5lz9IvGTD1uC1VFnGvFtbtYFipJA1V9enI knckwGNdOYVZvRf7o4GJOnQd1Vcvc9SQw6DvC4jjNcubQxr12+Dpnx95EmEdOLzBq9fb n2oPCMxS3kXb+DYIVVQABX7L0Hw2t7lbJteORYzvNPOjg/TzMUtxEQg2y+117TmXobvd hghXd7aMxVu9Ce98V5bxDlaLEtGU9nR/PtExrOxtHo7V60m7QPh5IKAKxc9iv8anRvgv gZdHHt31A0sdl01BDYD8DkIRmrO9XL80xkmqRnNBbBiHT9S9vLAp3vqd+txrjVju8zQA cejg== X-Gm-Message-State: AOJu0YxAQIpDtLktPjlJOTDXpeg6F93z9shc3rWtghjWh6jvuz3xll7G paZQGkBRtrsdP+hxc+lnA/V9oMSgEslG5AMdFqkJlkyNlUd+xvdzZJtUCzWiXwCWvSXVUteCVMq VGpqNkaevNiI25zWzAw5AfVLeHvc= X-Google-Smtp-Source: AGHT+IFv7Cw+Xdo/NpO2x3Ce8Hn84KTDTEnPTphAKAtJl7IcO4aecX7mGksDtE11ozAtxcjpbSPp2USsNc18ZsYsfro= X-Received: by 2002:a17:90a:eac8:b0:2a2:bc9d:f450 with SMTP id ev8-20020a17090aeac800b002a2bc9df450mr3495753pjb.0.1712220993096; Thu, 04 Apr 2024 01:56:33 -0700 (PDT) MIME-Version: 1.0 References: <20240328200319.4016902-1-jcmvbkbc@gmail.com> <20240328230116.GM4163@brightrain.aerifal.cx> <20240329014824.GG32430@brightrain.aerifal.cx> <20240403205555.GO4163@brightrain.aerifal.cx> In-Reply-To: <20240403205555.GO4163@brightrain.aerifal.cx> From: Max Filippov Date: Thu, 4 Apr 2024 01:56:22 -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 Wed, Apr 3, 2024 at 1:55=E2=80=AFPM Rich Felker wrote: > On Tue, Apr 02, 2024 at 07:30:57PM -0700, Max Filippov wrote: > > On Thu, Mar 28, 2024 at 6:48=E2=80=AFPM Rich Felker w= rote: > > > 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 wrote: > > > > > 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 ma= tch. > > > > > > > > > > Is this something related to canonical function descriptors? Is i= t > > > > > 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 canonica= l > > > 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(). > > Yes, I've been able to reproduce this and it's a clear bug. There does > not seem to be any way the dynamic linker could find these GOTFUNCDESC > slots to use them as a canonical address for the function, and I agree with that. It seems that it suggests that the SH FDPIC ABI document section "Function Addresses" needs at least a clarification regarding the "non-overridable functions". > moreover, they're not even unique; there would be one per library. --=20 Thanks. -- Max