[RISCV] Add zero-page relaxation

[ksco]

Currently, this patch fails at tests with -static option and needs more work to do before merging.

Also, seems TLS relaxation(#461) is already supported. We only have global-pointer relaxation(#460) left to do for RISC-V.

[rui314]

Generally looking good, but unlike R_RISCV_CALL_PLT, data may be referenced by HI20+LUI, so we need to handle section fragments when computing target addresses, no?

[ksco]

Thanks, the newly pushed code handles section fragments.

[ksco]

Also, the LUI -> C.LUI relaxation seems too restrictive and I don't know under what circumstances it would be triggered. For example, how do we write tests for this relaxation?

[rui314]

Also, the LUI -> C.LUI relaxation seems too restrictive and I don't know under what circumstances it would be triggered. For example, how do we write tests for this relaxation?

I believe you can place a function in its own section using __attribute__((section(".low"))) and place it at the very beginning of the virtual address space with -Wl,--section-start=.low=0x16.

I don't think LUI → C.LUI is useful on Unix, but it might be in embedded programming.

[ksco]

I believe you can place a function in its own section using __attribute__((section(".low")))...

Thanks, I added a c.lui test, but it segfaulted under riscv64, but I believe it's unrelated to this patch.

[rui314]

Maybe the first few pages are kept unmapped to catch null pointer accesses?

There might be no way to test this on Unix. If you wrote a bootloader-ish program, you could test it, but I doubt if it's necessary. I wouldn't implement LUI → C.LUI relaxation in the first place as it doesn't seem useful.

[ksco]

I created a separate bug #688.

[ksco]

I wouldn't implement LUI → C.LUI relaxation in the first place as it doesn't seem useful.

Agreed, I realized this after implementing, maybe I just remove this relaxation then.

[ksco]

@rui314 Thanks for the help, I think now it's ready for review.