RISC-V: fix some broken relocation handling

[mhorne]

Summary

In a few cases, the symbol lookup is missing before attempting to
perform the relocation. While the relocation types affected are
currently unused, this results in an uninitialized variable warning,
that is escalated to an error when building with clang.

--- elf_machdep.o ---
/usr/src/head/sys/riscv/riscv/elf_machdep.c:440:25: error: variable 'val' is uninitialized when used here [-Werror,-Wuninitialized]
                imm20 = calc_hi20_imm(val);
                                      ^~~
/usr/src/head/sys/riscv/riscv/elf_machdep.c:271:14: note: initialize the variable 'val' to silence this warning
        Elf_Addr val, addr;
                    ^
                     = 0
/usr/src/head/sys/riscv/riscv/elf_machdep.c:391:9: error: variable 'addr' is uninitialized when used here [-Werror,-Wuninitialized]
                val = addr - (Elf_Addr)where;
                      ^~~~
/usr/src/head/sys/riscv/riscv/elf_machdep.c:271:20: note: initialize the variable 'addr' to silence this warning
        Elf_Addr val, addr;
                          ^
                           = 0

[mhorne]

Note that I don't have any real way of testing this since as mentioned, none of these relocations are being emitted. I'm not entirely convinced that they are required at all, since this is the case even when compiling kmods without -fPIC. Could they be removed instead?

[markj]

In D21773#475113, @mhorne wrote:

Note that I don't have any real way of testing this since as mentioned, none of these relocations are being emitted. I'm not entirely convinced that they are required at all, since this is the case even when compiling kmods without -fPIC. Could they be removed instead?

This is really a @br question. :)

I don't think they impose much of a maintenance burden, so I'd be slightly inclined to keep them. They at least provide a starting point should these relocation types start to appear, and in that case we'll notice pretty quickly if any bugs are still lingering. I do not have strong feelings about it though.

[mhorne]

In D21773#475244, @markj wrote:

In D21773#475113, @mhorne wrote:

Note that I don't have any real way of testing this since as mentioned, none of these relocations are being emitted. I'm not entirely convinced that they are required at all, since this is the case even when compiling kmods without -fPIC. Could they be removed instead?

This is really a @br question. :)

I don't think they impose much of a maintenance burden, so I'd be slightly inclined to keep them. They at least provide a starting point should these relocation types start to appear, and in that case we'll notice pretty quickly if any bugs are still lingering. I do not have strong feelings about it though.

I decided to keep them in absence of any other input. You're right that they should not be much of a burden (other than this patch) and this choice can always be re-evaluated later.

As of this commit we are able to compile the GENERIC kernel completely with clang 9, and are not far off from the full suite of kernel modules.