Re: [musl] Initial xtensa/fdpic port review

[Max Filippov <jcmvbkbc@gmail.com>]

On Wed, Feb 28, 2024 at 10:30 AM Rich Felker <dalias@libc.org> wrote:
> On Wed, Feb 28, 2024 at 09:20:33AM -0800, Max Filippov wrote:
> > On Tue, Feb 27, 2024 at 4:12 PM Rich Felker <dalias@libc.org> wrote:
> > > >               } else {
> > > >                       size_t val = syms[R_SYM(rel[1])].st_value;
> > > >                       for (j=0; val-segs[j].p_vaddr >= segs[j].p_memsz; j++);
> > > >                       *rel_addr = rel[2] + segs[j].addr - segs[j].p_vaddr + val;
> > > >               }
> > > >       }
> > > > +#ifdef __xtensa__
> > > > +     ((unsigned long *)dyn[DT_PLTGOT])[3] = segs[0].addr - segs[0].p_vaddr;
> > > > +#endif
> > >
> > > Is this actually needed for anything? Generally musl doesn't use the
> > > reserved GOT slots itself, and on all the other archs I'm aware of,
> > > they're essentially reserved to the dynamic linker implementation so
> > > the dynamic linker is just free not to use them and not to set them
> > > up.
> >
> > xtensa doesn't have relative register jumps and calls, so local jumps
> > and calls to a far off locations need to use absolute target addresses.
> > One possible solution is to have the address in the GOT entry, the
> > other is to calculate the target address using the text segment load
> > offset at runtime. Both have the same instruction count, see
> >   http://wiki.osll.ru/doku.php/etc:users:jcmvbkbc:binutils-xtensa#local_call
> > for the details, but the latter doesn't waste GOT space and that saves
> > a noticeable amount of RAM.
>
> I see. Doesn't this limit you to a single text segment, though? In
> practice it might not matter, but it's more constraining than fdpic
> was designed to be.

Instead of a fixed dedicated GOT entry there can be multiple
entries, one per independent text segment, giving the maximum of
1024 / 4 - 3 = 253 text segments addressable with this technique.
Instead of generating a fixed load from GOT + 12 there would be a
relocation against that load instruction mentioning the target symbol
and the linker would have a chance to allocate GOT space, fix up
offsets in these instructions and add dynamic relocations against
these GOT entries that would produce runtime load offsets for the
corresponding text segments.

-- 
Thanks.
-- Max