[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
