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=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 49A0628B21 for ; Wed, 3 Apr 2024 22:55:52 +0200 (CEST) Received: (qmail 15613 invoked by uid 550); 3 Apr 2024 20:55:44 -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 15574 invoked from network); 3 Apr 2024 20:55:44 -0000 Date: Wed, 3 Apr 2024 16:55:56 -0400 From: Rich Felker To: Max Filippov Cc: musl@lists.openwall.com Message-ID: <20240403205555.GO4163@brightrain.aerifal.cx> References: <20240328200319.4016902-1-jcmvbkbc@gmail.com> <20240328230116.GM4163@brightrain.aerifal.cx> <20240329014824.GG32430@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [RFC v2 0/2] xtensa FDPIC port On Tue, Apr 02, 2024 at 07:30:57PM -0700, Max Filippov wrote: > On Thu, Mar 28, 2024 at 6:48 PM Rich Felker wrote: > > On Thu, Mar 28, 2024 at 05:48:50PM -0700, Max Filippov wrote: > > > On Thu, Mar 28, 2024 at 4:00 PM 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 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(). 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 moreover, they're not even unique; there would be one per library. The code path for legitimize_pic_address in sh.c that emits GOTFUNCDESC has the wrong logic. A simple fix would be just making that path never be taken, but I'm not sure if that would break use of GOTFUNCDESC for pure-call purposes. The condition should probably be something like: if it's just used for a call (if this is even needed; pure call is probably handled elsewhere) or if the function is static or hidden, use GOTFUNCDESC; otherwise, use GOT. I might try patching it and see what happens. Rich