[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240229153531.GT4163@brightrain.aerifal.cx>
Date: Thu, 29 Feb 2024 10:35:31 -0500
From: Rich Felker <dalias@...c.org>
To: Max Filippov <jcmvbkbc@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Initial xtensa/fdpic port review
On Thu, Feb 29, 2024 at 04:03:02AM -0800, Max Filippov wrote:
> On Wed, Feb 28, 2024 at 1:28 PM Max Filippov <jcmvbkbc@...il.com> wrote:
> > On Wed, Feb 28, 2024 at 10:30 AM Rich Felker <dalias@...c.org> wrote:
> > > Is there a reason local, relative jumps/calls can't be done by
> > > computing the address of a nearby label and using the offset relative
> > > to that? That's how they (at least some types; I forget the details)
> > > work on sh/fdpic.
> >
> > IIUC that would require the actual PC knowledge and there's no direct
> > access to the PC on xtensa.
>
> I thought about it for a bit and although the current PC can easily
> be fetched I don't see how it can work for multiple text segments
> without a GOT entry. OTOH a link-time conversion of a call without
> GOT to a call with GOT in case the target and the call site are in
> the different text segments seems feasible.
With multiple text segments, a cross-segment call cannot be relative
to begin with. Because fdpic lets them float independently, it would
have to go thru the GOT.
Rather than having the linker convert calls *to* using GOT, I think
the safe way to do things would be to have the compiler emit calls
thru the GOT but linker relax them to avoid the GOT when they're in
the same segment. But there's no reason this has to be done initially.
I'm just thinking in terms of making sure the design doesn't preclude
or make it difficult to do multiple segments in the future if desired.
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.
