[PATCH] MIPS: support PCREL GOT access

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2024年2月5日周一 21:00写道：
>
> On Mon, 5 Feb 2024, Nick Clifton wrote:
>
> > > Any idea how to write ld testcases?
> > > Normal readelf/objdump can only be sure that it is linked.
> > > I think that we need to execute the out objects to be sure that it has no
> > > problems, such as segfault etc.
> >
> > You can use the [isnative] test to check to see if the test
> > is being run natively and then try executing the linked code.
>
>  This will limit verification however, especially for such a target as the
> MIPS one, usually found in embedded devices only and therefore typically
> only verified in a cross-environment.  I can't remember when I last run
> verification with the MIPS target natively if ever.  It just takes too
> long for regular use, and it can obviously only cover whatever the subset
> of ISA features is that the native system provides.
>

Yes. It is a problem, thus I try to use qemu user to run GCC testcase.
In fact not yet for binutils.
https://wiki.debian.org/QemuUserEmulation/GccCheckWithQemuUser

>  The proper way to handle such verification is to tighten the test cases.
> Relocations have well-defined semantics, so you can prepare sources such
> as to get reproducible output you can then match against.  That means
> verifying exact bit patterns in files produced, and you can arrange for
> boundary cases, such as carry/borrow or overflow, to be verified where
> applicable too.  We have such detailed cases in our testsuite already.
>

In fact I am worried that we use the wrong GOT slot, and the ldso
set the GOT incorrectly for use., which is not easy to test statically.
Bit by bit comparison is not easy, due to that the final executables
contains something from libc, which may have quite different versions.

>  Relying on run-time tests to crash if a relocation calculation goes wrong
> seems rather fragile to me.  I can imagine errors to cancel each other for
> example.
>

Yes. We should check statically as possible as we can.

>   Maciej