[PATCH] Allow memset local PLT reference for RISC-V.

[Alistair Francis]

On Sat, Jul 11, 2020 at 6:32 PM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Fri, 10 Jul 2020, Alistair Francis wrote:
>
> > > > Anyways, if you want to know where the PLT call is coming from, you
> > > > can't rely on the relocs.  R_RISCV_CALL_PLT is not necessarily a plt
> > > > call.
> > >
> > >  If a PLT entry has been created, then the linker must have considered the
> > > symbol referred preemptible, whether legitimately or not.
> > >
> > >  Rather than scratching one's head I would suggest running the relevant LD
> > > invocation under GDB to find out what really happens there, which may be
> > > as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
> > > the right condition on the hash entry so as to stop on `memset' only, and
> > > then working backwards with a watchpoint (on a host system that does not
> > > use ASLR) to find out what sets `h->plt.offset'.  There'll be the answer.
> >
> > I tried to look into this but haven't made much progress here. If
> > anyone has more ideas they would be very welcome otherwise I'll keep
> > digging into this.
>
>  The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
> bfd/elfnn-riscv.c:
>
>         case R_RISCV_CALL_PLT:
>           /* This symbol requires a procedure linkage table entry.  We
>              actually build the entry in adjust_dynamic_symbol,
>              because this might be a case of linking PIC code without
>              linking in any dynamic objects, in which case we don't
>              need to generate a procedure linkage table after all.  */
>
>           if (h != NULL)
>             {
>               h->needs_plt = 1;
>               h->plt.refcount += 1;
>             }
>           break;
>
> due to a reference from `addtf3.o', from `libgcc.a'.  There are further 20
> references for a total of 21.  There is a later opportunity for the flag
> to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
> comment, however that only happens for symbols that bind locally, or which
> are not referenced, and for `memset' obviously neither is the case (and
> `allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
> then).
>
>  I don't think we have a way to redirect the reference to `__GI_memset'.

I'm not really clear where this ended up. I have a session at Plumbers
next week to discuss the RV32 port and am planning on discussing this
issue as well.

It would be great if as many people as possible could be there.

https://linuxplumbersconf.org/event/7/contributions/809/

Alistair

>
>   Maciej