Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.)

[Zack Weinberg <zackw at panix dot com>]

On Thu, Mar 22, 2018 at 7:47 PM, Alan Modra <amodra@gmail.com> wrote:
>
> Yes, the error message isn't the best in this case.  At one stage GNU
> ld did allow code like you're writing.  ie. a useless nop to be
> replaced with a toc restore insn that won't ever be executed.  It
> was a way for an assembly programmer to say they knew what they were
> doing, please don't complain "can't restore toc".  I took that feature
> out after getting reports of crashes due to bad toc pointer values..

Yeah, this is subtle enough that I think that was probably the right call...

...
> Do you need lazy linking of the __libc_vfork PLT entry?  If not, you
> could just implement the stub as an indirect call to __libc_vfork.

Lazy linking would be _better_, since these stubs exist only for
compatibility with old executables and shouldn't get called very
often, but I think we can live with eager linking.  It's probably not
a measurable difference in the time it takes to load libpthread.so
anyway.

> For ELFv2, something like:
...

Thanks, I was trying to work these out myself (see the message I sent
to binutils@) and got stuck because the ABI spec uses
pseudo-relocation notation that the assembler doesn't actually accept.
It was also not clear to me that ELFv2 scrapped function descriptors;
you wouldn't happen to know where there's a list of *changes* from v1
to v2, would you?

>  .text
> 0:
>  addis 11,2,1f-0b@ha
>  addi 11,11,1f-0b@l
>  ld 11,0(11)
>  ld 12,0(11)
>  mtctr 12
>  ld 2,8(11)
>  ld 11,16(11)

Is this third load (to r11) from the function descriptor required?
That's the static chain slot, which C doesn't use, I thought...

zw