[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240403205555.GO4163@brightrain.aerifal.cx>
Date: Wed, 3 Apr 2024 16:55:56 -0400
From: Rich Felker <dalias@...c.org>
To: Max Filippov <jcmvbkbc@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [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 <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
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
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.
