[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMo8Bf+4gHy-ndptG-zG5oVFU0oEp+f2HxHk0zaoo9-uv75BQQ@mail.gmail.com>
Date: Tue, 2 Apr 2024 19:30:57 -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 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().
--
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.
