cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 [1.21 backport]

[gopherbot]

@ianlancetaylor requested issue #62465 to be considered for backport to the next 1.21 minor release.

@gopherbot Please open backport to 1.21.

This is a build failure with no straightforward workaround. It is a regression from 1.20.

[thanm]

Hi @4a6f656c the deadline for the next set of minor releases is approaching; let me know if you think you will be able to create cherry-picks for 1.21.2 or whether we'll need to punt this backport to 1.21.3, thanks. Last day for 1.21.2 cherry-picks is tomorrow. Thanks.

[cherrymui]

Personally I feel CL https://go.dev/cl/520095 is pretty complex for a backport. Could we find a simpler workaround?
On the other hand, this is RISCV only, so if the RISCV port maintainers are fine with this, I'm okay. Thanks.

[4a6f656c]

@thanm apologies for not seeing this earlier.

I agree with @cherrymui that this is a fairly complex backport - given that the probability of hitting this is very low and that there is a known/documented workaround, I question if a backport is even justified.

If a backport is still considered necessary, I can see what simpler option I can come up with, however that may take a week or so. One option would be to disable the map init deadcode handling on riscv64, which would avoid the first/only known case that triggers the linker bug (i.e. hard code the workaround).

[thanm]

Turning off map init deadcode for riscv64 seems like it would be a decent option, I am ok with that.

[cherrymui]

however that may take a week or so

The next minor release will be early November (there will be one this week, but that is already cut). So timing shouldn't be a problem.

Disabling map init deadcode for riscv64 seems reasonable. Or if adding a relocation type to IsDirectCall (or even specifically in map init deadcode code) works without other issues, we could do that. Thanks.