![]() |
|
Message-ID: <CAMo8BfLvBWdmJiMr2bBX7H-7m7-yfEyPx66tEhV_BVkLjsFhFg@mail.gmail.com> Date: Thu, 4 Apr 2024 01:56:22 -0700 From: Max Filippov <jcmvbkbc@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: [RFC v2 0/2] xtensa FDPIC port On Wed, Apr 3, 2024 at 1:55 PM Rich Felker <dalias@...c.org> wrote: > On Tue, Apr 02, 2024 at 07:30:57PM -0700, Max Filippov wrote: > > On Thu, Mar 28, 2024 at 6:48 PM Rich Felker <dalias@...c.org> 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 <dalias@...c.org> 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 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. -- Thanks. -- Max
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.