RFR: 8332689: RISC-V: Use load instead of trampolines [v8]

[Robbin Ehn]

On Wed, 12 Jun 2024 07:42:54 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Ah, that doesn't seems to be easier than before ~. I am not familar with s390 and I didn't see where it updates the target address in CP. I will take another look at our current approach and see if there are further improvements we can do.

I have tested a few different approaches, as we are crossing code sections we need to track this.
The two which seems most reasoanble is:
- Add offset to the four relocators static/virt/opt/runtime as RV only.
  When we set the destination on relocation we update the instructions to point to CP + offset (where we get offset from relocator), and finally set the new destination at this location.
- Add a second relocator to the call which tracks the constant pool address.
  When we set the destination on relocation we lookup the second relocator and get the address from it, and finally set the dest at this location.
- Maybe there is a smarter way not apparent to me?

As there is a lot of assumptions about relocators both requires random shared code changes.
E.g. CodeBuffers with 0 sized CP, assuming only one relocator for PC-range, etc...

I suggest this require a more elaborate fix as I would want to add support for global table (in range of auipc+ld from CC) where we can put shared addresses. I think the second solution with additional relocator where we just get the address, which then could either be local CP or global CP would be best?
Hence I'm suggesting this work would be done outside this PR, and suggest we keep using stubs for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19453#issuecomment-2164794944